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Gran parte de los libros sobre sistemas operativos se centran mucho en la teoría y poco en la práctica. El 
presente libro intenta ofrecer un mayor equilibrio entre una y otra; trata todos los principios fundamentales 
con gran detalle, entre ellos, los procesos, la comunicación entre proce sos, semáforos, monitores, 
transferencia de mensajes, algoritmos de planificación, entrada/salida, bloqueos mutuos, controladores de 
dispositivos, administración de memoria, algoritmos de pagi nación, diseño de sistemas de archivos, 
seguridad y mecanismos de protección, pero también examina un sistema específico —MINIX, un sistema 
operativo compatible con UNIX— detallada mente, e incluso proporciona un listado completo del código 
fuente para estudiarlo. Esta organi zación permite al lector no sólo aprender los principios, sino también 
ver cómo se aplican en un sistema operativo real. 

Cuando apareció la primera edición de este libro en 1987, causó una especie de revolución en la 
forma de impartir los cursos de sistemas operativos. Hasta entonces, la mayor parte de los cursos sólo 
abordaban la teoría. Con la aparición de MINIX, muchas escuelas comenzaron a oiré cer cursos de 
laboratorio en los que los estudiantes examinaban un sistema operativo real para ver cómo funcionaba 
internamente. Consideramos que esta tendencia es altamente favorable y espe ramos que esta segunda 
edición la fortalezca. 

En sus primeros 10 años, MINIX ha sufrido muchos cambios. El código original se diseñó 
para una IBM PC de 256 K basada en 8088 con dos unidades de disquete y sin disco duro; 
además, se basaba en la Versión 7 de UNIX. Con el paso del tiempo, MINIX evolucionó en muchas 
direcciones. Por ejemplo, la versión actual se ejecuta en máquinas desde la PC original (en modo 
real de 16 bits) hasta las Pentium grandes con discos duros de gigabytes (en modo protegido de 32 
bits). Además, MINIX se basa ahora en el estándar internacional POSIX (IEEE 1003.1 e ISO 9945-1) en 


xv 



xvi 


PREFACIO 


lugar de la Versión 7. Por último, se agregaron muchas características, tal vez demasiadas en nuestra 
opinión, pero no suficientes según otras personas; esto dio pie a la creación de LINUX. Además, MINIX 
se llevó a muchas otras plataformas, incluidas Macintosh, Amiga, Atari y SPARC. Este libro sólo trata 
MINIX 2.0, que hasta ahora sólo se ejecuta en computadoras con una CPU 80x86, en sistemas que pueden 
emular tal CPU, o en SPARC. 

Esta segunda edición del libro tiene muchos cambios en todas sus partes. Casi todo el material sobre 
principios ha sido revisado, y se ha agregado una cantidad considerable de material nuevo. Sin embargo, 
el cambio principal radica en la explicación del nuevo MINIX basado en POSIX, y la inclusión del nuevo 
código en este libro. Otra cosa nueva es la inclusión de un CD-ROM en cada libro con el código fúente 
completo de MIMX junto con instrucciones para instalar MINIX en una PC (véase el archivo 
README.TXT en el directorio principal del CD-ROM). 

La configuración de MINIX en una PC 80x86, sea para uso individual o en el laboratorio, es 
sencilla. Primero se debe crear una partición de disco de, por lo menos, 30 MB para él; luego puede 
instalarse MINIX siguiendo las instrucciones del archivo README. TXT del CD-ROM. Si desea 
imprimir el archivo README.TXTen una PC, primero inicie MS-DOS, si no se está ejecutando ya (desde 
WINDOWS, haga clic en el icono MS-DOS), y luego teclee 
copy readme.txt pm 

para producir el listado. El archivo también puede examinarse en edit, wordpad, notepad o cualquier otro 
editor de texto que pueda manejar texto ASCII simple. 

Para las escuelas (o individuos) que no cuentan con una PC, ahora hay otras dos opciones. Se 
incluyen dos simuladores en el CD-ROM. Uno, escrito por Paul Ashton, trabaja en SPARC, ejecutando 
MINIX como programa de usuario encima de Solaris. En consecuencia, MINIX se compila para producir 
un binario de SPARC y se ejecuta a toda velocidad. En esta modalidad, MINIX ya no es un sistema 
operativo, sino un programa de usuario, lo cual hizo necesarios ciertos cambios en el código de bajo nivel. 

El otro simulador íue escrito por Kevin P. Lawton de Bochs Software Company. Este simulador 
interpreta el conjunto de instrucciones 80386 y suficientes aditamentos de E/S como para que MINIX 
pueda ejecutarse en el simulador. Desde luego, al ejecutarse encima de un intérprete el rendimiento decae, 
pero los estudiantes pueden realizar la depuración con mucha mayor facilidad, Este simulador tiene la 
ventaja de que se ejecuta en cualquier computadora que maneja el sistema X Ventana del M.I.T. Si desea 
mayor información acerca de los simuladores, remítase al CD-ROM, 

El desarrollo de MINIX es un proyecto que continúa. El contenido de este libro y del CD-ROM son 
sólo una instantánea del sistema en el momento de la publicación. Si le interesa el estado actual del 
sistema, puede ver la página base de MINIX en la World Wide Web, http:/Iwww.cs.vu.nl/ 
‘ast/minix.html, Además, MINIX tiene su propio grupo de noticias USENET: comp.os.minix, al cual 
pueden suscribirse los lectores para averiguar qué es lo que sucede en el mundo de MINIX. Para quienes 
cuentan con correo electrónico, pero no con acceso a grupos de noticias, también hay una lista de correo. 
Escriba a listserv@listserv.nodak.edu con “subscribe minix-1 <su nombre completo>” como primera y 
única línea del cuerpo del mensaje. A vuelta de correo electrónico recibirá mayor información. 
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Para uso en el aula, se pueden obtener archivos PostScript que contienen todas las ilustraciones del 
libro, y que son apropiados para crear diapositivas, siguiendo el enlace marcado como “Soft ware aud 
supplementary material” de http.Y/wwwcs.vu.nl/ 

Hemos tenido la enorme suerte de contar con la ayuda de muchas personas durante la realiza ción de 
este proyecto. Antes que nada, nos gustaría agradecer a Kees Bot el haber realizado la mayor parte del 
trabajo necesario para hacer que MINIX se ajustara al estándar, además de haber organizado la 
distribución. Sin su generosa ayuda, nunca habríamos completado el proyecto. Él mismo escribió grandes 
trozos del código (p. ej., la E/S de terminal de Posix), depuró otras sec ciones y reparó numerosos errores 
que se habían acumulado al pasar los años. Muchas gracias por un trabajo bien hecho. 

Bruce Evans, Philip Homburg, Will Rose y Michael Teman han contribuido al desarrollo de MINIX 
durante muchos años, Cientos de personas más han contribuido con MINIX a través del grupo de noticias; 
son tantos y sus contribuciones han sido tan variadas que no podríamos siquiera comenzar a mencionarlos 
a todos aquí, así que lo mejor que podemos hacer es expresar un agrade cimiento generalizado a todos 
ellos. 

Varias personas leyeron partes del manuscrito e hicieron sugerencias. Nos gustaría dar las gracias 
especialmente a John Casey, Dale Grit y Frans Kaashoek. 

Varios estudiantes de la Vrije Universiteit probaron la versión beta del CD-ROM. Ellos fue ron: 
Ahmed Batou, Goran Dokic, Peter Gijzel, Thomer Gil, Dermis Grimbergen, Roderick Groesbeek, Wouter 
Haring, Guido Kollerie, Mark Lassche, Raymond Ris, Frans ter Borg, Alex van Ballegooy, Ries van der 
Velden, Alexander Wels y Thomas Zeeman. Nos gustaría agradecer a todos ellos lo cuidadoso de su 
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INTRODUCCIÓN 


Sin su software, la computadora es básicamente un montón de metal inútil. Con su software, una 
computadora puede almacenar, procesar y recuperar información; exhibir documentos multimedia; 
realizar búsquedas en Internet; y realizar muchas otras actividades valiosas para justificar su existencia. El 
software de computadora puede dividirse a grandes rasgos en dos tipos: programas de sistema, que 
controlan la operación de la computadora misma, y programas de aplicación, que realizan las tareas reales 
que el usuario desea. El programa de sistema más fúndamental es el sistema operativo, que controla 
todos los recursos de la computadora y establece la base sobre la que pueden escribirse los programas de 
aplicación. 

Un sistema de computadora moderno consiste en uno o más procesadores, memoria principal 
(también conocida como RAM, memoria de acceso aleatorio), discos, impresoras, interfaces de red y 
otros dispositivos de entrada/salida. A todas luces, se trata de un sistema complejo. Escribir programas 
que sigan la pista a todos estos componentes y los usen correctamente, ya no digamos óptimamente, es 
una tarea en extremo difícil. Si todos los programadores tuvieran que ocuparse de cómo trabajan las 
unidades de disco, y de las docenas de cosas que pueden fallar al leer un bloque de disco, es poco probable 
que pudieran escribirse muchos programas. 

Hace muchos años se hizo muy evidente que debía encontrarse alguna forma de proteger a 
los programadores de la complejidad del hardware. La solución que ha evolucionado gradualmente 
consiste en poner una capa de software encima del hardware solo, que se encargue de administrar 
todas las partes del sistema y presente al usuario una interfaz o máquina virtual que sea más 
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fácil de entender y programar. Esta capa de software es el sistema operativo, y constituye el tema de este 
libro. 

La situación se muestra en la Fig. 1-1. En la parte inferior está el hardware que, en muchos casos, 
también se compone de dos o más capas. La capa más baja contiene los dispositivos físicos, que consisten 
en chips de circuitos integrados, alambres, fuentes de potencia, tubos de rayos catódicos y otros aparatos 
físicos similares. La forma en que éstos se construyen y sus principios de funcionamiento pertenecen al 
campo del ingeniero electricista. 



Programas de aplicación 


Programas de sistema 


Hardware 


Figura 1-1. Un sistema de computadora consiste en hardware, programas 
de sistema y programas de aplicación. 


A continuación (en algunas máquinas) viene una capa de software primitivo que controla 
directamente estos dispositivos y ofrece una interfaz más aseada a la siguiente capa. Este software, 
llamado microprograma, suele estar almacenado en memoria de sólo lectura. En realidad es un 
intérprete, que obtiene las instrucciones de lenguaje de máquina como ADD, MOVE y JUMP y las 
ejecuta en una serie de pasos pequeños. Por ejemplo, para ejecutar una instrucción ADD (sumar), el 
microprograma debe determinar dónde se encuentran los números que se van a sumar, obtenerlos, 
sumarlos y almacenar el resultado en algún lugar. El conjunto de instrucciones que el microprograma 
interpreta define el lenguaje de máquina, que no es realmente parte de la máquina física, aunque los 
fabricantes de computadoras siempre lo describen en sus manuales como tal, de modo que muchas 
personas piensan en él como si fúera la “máquina” real. 

Algunas computadoras, llamadas RISC (computadoras con conjunto de instrucciones reducido), 
no tienen un nivel de microprogramación. En estas máquinas, el hardware ejecuta las instrucciones de 
lenguaje de máquina directamente. Por ejemplo, el Motorola 680x0 tiene un nivel de 
microprogramación, pero el IBM PowerPC no. 

El lenguaje de máquina por lo regular cuenta con entre 50 y 300 instrucciones, la mayor parte de 
ellas para trasladar datos dentro de la máquina, realizar operaciones aritméticas y comparar valores. En 
esta capa, los dispositivos de entrada/salida se controlan cargando valores registros de 
dispositivo especiales. Por ejemplo, para un disco que ejecuta una lectura, sus registros se cargan 

con los valores de dirección del disco, dirección de memoria principal, conteo de bytes y dirección de 
acceso (READ o WRITE). En la práctica se requieren muchos parámetros más, y el 
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estado devuelto por la unidad de disco después de una operación es muy complejo. Además, la 
temporización desempeña un papel importante en la programación de muchos dispositivos de E/S. 

Una función importante del sistema operativo es ocultar toda esta complejidad y ofrecer al 
programador un conjunto de instrucciones más cómodo con el que pueda trabajar. Por ejemplo, LEER 
BLOQUE DE ARCHIVO es conceptualmente más sencillo que tener que preocuparse por los detalles de 
mover cabezas de disco, esperar que se estabilicen, etcétera. 

Encima del sistema operativo está el resto del software de sistema. Aquí encontramos el intérprete de 
comandos (shell), sistemas de ventanas, compiladores, editores y otros programas si mi lares 
independientes de la aplicación. Es importante darse cuenta de que estos programas definitivamente no 
forman parte del sistema operativo, a pesar de que casi siempre son provistos por el fabricante de la 
computadora. Éste es un punto crucial, aunque sutil. El sistema operativo es la porción del software que 
se ejecuta en modo kernel o modo supervisor, y está protegido por el hardware contra la intervención 
del usuario (olvidándonos por el momento de algunos de los microprocesadores más viejos que no 
tienen ninguna protección de hardware). Los compiladores y editores se ejecutan en modo de usuario. Si 
a un usuario no le gusta un compilador en particular, él + está en libertad de escribir el suyo propio si lo 
desea; no está en libertad de escribir su propio manejador de interrupciones del disco, que forma parte del 
sistema operativo y normalmente está protegido por el hardware contra los intentos de los usuarios por 
modificarlo. 

Por último, encima de los programas de sistema vienen los programas de aplicación. Los usuarios 
compran o escriben estos programas para resolver sus problemas particulares, como procesamiento de 
textos, hojas de cálculo, cálculos de ingeniería o juegos. 


¿QUÉ ES UN SISTEMA OPERATIVO? 


La mayoría de los usuarios de computadora han tenido algo de experiencia con un sistema operativo, 
pero no es fácil precisar con exactitud qué es un sistema operativo. Parte del problema consiste en 
que el sistema operativo realiza dos funciones que básicamente no están relacionadas entre sí y, 
dependiendo de a quién le preguntemos, por lo general se nos habla principalmente de una función o de la 
otra. Veamos ahora las dos. 


1.1.1 El sistema operativo como máquina extendida 

Como ya dijimos, la arquitectura (conjunto de instrucciones, organización de memoria, E/S y estructura 
de buses) de la mayor parte de las computadoras en el nivel de lenguaje de máquina es primitiva y difícil 
de programar, sobre todo para entrada/salida. A fin de hacer más concreto este punto, veamos 
brevemente cómo se realiza la E/S de disco flexible usando el chip controlador NEC PD765 
(o su equivalente), utilizado por la mayor parte de las computadoras personales. (En 
todo este libro usaremos indistintamente los términos “disco flexible” y “disquete”.) El PD765 


f “Él” debe leerse “él o ella” a lo largo de todo el libro. 
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tiene 16 comandos, cada uno de los cuales se especifica cargando entre 1 y 9 bytes en un registro de 
dispositivo. Estos comandos sirven para leer y escribir datos, mover el brazo del disco y formatear pistas, 
así como para inicializar, detectar, restablecer y recalibrar el controlador y las unidades de disco. 

Los comandos más básicos son READ y WRITE, cada uno de los cuales requiere 13 parámetros 
empacados en 9 bytes. Estos parámetros especifican cosas tales como la dirección del bloque de disco que 
se va a leer, el número de sectores por pista, el modo de grabación empleado en el medio físico, el 
espaciado de la brecha entre sectores y qué hacer con una marca de “dirección de datos eliminada”. Si 
usted no entiende a qué nos referimos, no se preocupe; de eso se trata precisamente: es algo muy 
esotérico. Cuando se completa la operación, el chip controlador devuelve 23 campos de estado y error 
empacados en 7 bytes. Por si esto no fuera suficiente, el programador del disco flexible también debe tener 
presente en todo momento si el motor está encendido o apagado. Si el motor está apagado, debe 
encenderse (con un retardo de arranque largo) antes de que puedan leerse o escribirse datos. Empero, el 
motor no puede dejarse encendido demasiado tiempo, pues el disco flexible se desgastaría. Por tanto, el 
programador debe encontrar un equilibrio entre los retardos de arranque largos y el desgaste de los discos 
flexibles (y la pérdida de los datos que contienen). 

Sin entrar en los verdaderos detalles, debe quedar claro que el programador ordinario segura- mente 
no quiere intervenir de manera demasiado íntima en la programación de los discos flexibles (o de los 
duros, que son igualmente complejos, y muy distintos). En vez de ello, lo que el programador quiere es 
manejar una abstracción sencilla, de alto nivel. En el caso de los discos, una abstracción típica sería que el 
disco contiene una colección de archivos con nombre. Cada archivo puede abrirse para lectura o escritura, 
leerse o escribirse, y por último cerrarse. Los detalles de si la grabación debe usar o no modulación de 
frecuencia modificada y cuál es la situación actual del motor no deberán aparecer en la abstracción 
presentada al usuario. 

El programa que oculta la verdad acerca del hardware y presenta al programador una vista sencilla y 
bonita de archivos con nombre que pueden leerse y escribirse es, por supuesto, el sistema operativo. Así 
como el sistema operativo aísla al programador del hardware del disco y presenta una interfaz sencilla 
orientada a archivos, también oculta muchos asuntos desagradables referentes a interrupciones, 
temporizadores, administración de memoria y otras funciones de bajo nivel, En cada caso, la abstracción 
que el sistema operativo ofrece es más sencilla y fácil de usar que el hardware subyacente. 

En esta vista, la función del sistema operativo es presentar al usuario el equivalente de una máquina 
extendida o máquina virtual que es más fácil de programar que el hardware subyacente. La forma en 
que el sistema operativo logra este objetivo es una historia larga, que estudiaremos con detalle a lo largo 
del libro. 


1.1.2 El sistema operativo como administrador de recursos 

El concepto del sistema operativo como algo cuya función primordial es ofrecer a los usuarios una 
Interfaz cómoda es una visión descendente. Una visión ascendente alternativa postula que el 
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sistema operativo está ahí para administrar todos los componentes de un sistema complejo. Las 
computadoras modernas constan de procesadores, memorias, temporizadores, discos, ratones, interfaces 
con redes, impresoras láser y una gran variedad de otros dispositivos. En la visión alternativa, la misión 
del sistema operativo es asegurar un reparto ordenado y controlado de los procesadores, memorias y 
dispositivos de E/S entre los diferentes programas que compiten por ellos. 

Imagine lo que sucedería si tres programas que se ejecutan en alguna computadora trataran de imprimir 
sus salidas simultáneamente en la misma impresora. Las primeras líneas del listado podrían ser del 
programa 1, las siguientes del programa 2, luego algunas del programa 3, y así sucesivamente. El 
resultado sería un caos. El sistema operativo puede poner orden en el caos potencial almacenando 
temporalmente en el disco todas las salidas destinadas para la impresora. Cuan- do un programa haya 
terminado, el sistema operativo podrá copiar su salida del archivo de disco donde se almacenó a la 
impresora, mi entras que el otro programa puede continuar generando salidas, ajeno al hecho de que dichas 
salidas no están yendo directamente a la impresora (todavía). 

Cuando una computadora (o red) tiene múltiples usuarios, la necesidad de administrar y proteger la 
memoria, los dispositivos de E/S y demás recursos es aún mayor, ya que de otra manera los usuarios 
podrían interferirse. Además, es frecuente que los usuarios tengan que compartir no sólo hardware, sino 
también información (archivos, bases de datos, etc.). En pocas palabras, esta es visión del sistema 
operativo sostiene que su tarea primordial es seguir la pista de quién está usan-do cuál recurso, atender 
solicitudes de recursos, contabilizar la utilización y mediar entre solicitudes en conflicto provenientes de 
diferentes programas y usuarios. 


1.2 HISTORIA DE LOS SISTEMAS OPERATIVOS 

Los sistemas operativos han estado evolucionando durante muchos años. En las siguientes secciones 
examinaremos brevemente este desarrollo. Dado que, históricamente, los sistemas operativos han estado 
de manera muy estrecha vinculados con la arquitectura de las computadoras en las que se ejecutan, 
estudiaremos las sucesivas generaciones de computadoras para ver qué clase de sistemas operativos 
usaban. Esta correspondencia entre las generaciones de sistemas operativos y de computadoras es algo 
burda, pero establece un poco de estructura que de otra forma sería inexistente. 

La primera computadora digital verdadera fue diseñada por el matemático inglés Charles Babbage 
(1792-1871). Aunque Babbage invirtió la mayor parte de su vida y su fortuna tratando de construir su 
“máquina analítica”, nunca logró que funcionara correctamente porque era totalmente mecánica, y la 
tecnología de su época no podía producir las ruedas, engranes y levas con la elevada precisión que él 
requería. Huelga decir que la máquina analítica no contaba con un sistema operativo. 

Como acotación histórica interesante, diremos que Babbage se dio cuenta de que necesitaría software 
para su máquina analítica, así que contrató a una joven mujer, Ada Lovelace, hija del famoso poeta 
británico, Lord Byron, como la primera programadora de la historia. El lenguaje de programación Ada® 
recibió su nombre en honor a ella. 
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1.2.1 La primera generación (1945-55): Tubos de vacío 
y tableros de conmutación 

Después del fracaso de los trabajos de Babbage, fueron pocos los avances que se lograron en la 
construcción de computadoras digitales hasta la Segunda Guerra Mundial. A mediados de la década de 
1940, Howard Aiken en Harvard, John von Neumann en el Institute for Advanced Study en Princeton, J. 
Presper Eckert y William Mauchley en la University of Pennsylvania y Konrad Zuse en Alemania, entre 
otros, lograron construir máquinas calculadoras usando tubos de vacío. Estas máquinas eran enormes, y 
ocupaban cuartos enteros con decenas de miles de tubos de vacío, pero eran mucho más lentas que 
incluso las computadoras personales más baratas de la actualidad. 

En esos primeros días, un solo grupo de personas diseñaba, construía, programaba, operaba y 
mantenía a cada máquina. Toda la programación se realizaba en lenguaje de máquina absoluto, a menudo 
alambrando tableros de conmutación para controlar las funciones básicas de la máquina. No existían los 
lenguajes de programación (ni siquiera los de ensamblador). Nadie había oído hablar de los sistemas 
operativos. La forma de operación usual consistía en que el programador se anotaba para recibir un 
bloque de tiempo en la hoja de reservaciones colgada en la pared, luego bajaba al cuarto de la máquina, 
insertaba su tablero de conmutación en la computadora, y pasaba las siguientes horas con la esperanza de 
que ninguno de los cerca de 20000 tubos de vacío se quemara durante la sesión. Prácticamente todos los 
problemas eran cálculos numéricos directos, como la producción de tablas de senos y cosenos. 

A principios de la década de 1950, la rutina había mejorado un poco con la introducción de las 
tarjetas perforadas. Ahora era posible escribir programas en taijetas e introducirlas para ser leídas, en lugar 
de usar tableros de conmutación; por lo demás, el procedimiento era el mismo. 


1.2.2 La segunda generación (1955-65): Transistores y sistemas por lote 

La introducción del transistor a mediados de la década de 1950 alteró el panorama radicalmente. Las 
computadoras se hicieron lo bastante confiables como para poderse fabricar y vender a clientes 
comerciales con la expectativa de que seguirían funcionando el tiempo suficiente para realizar algo de 
trabajo útil. Por primera vez, había una separación clara entre diseñadores, constructores, operadores, 
programadores y personal de mantenimiento. 

Estas máquinas se encerraban en cuartos de computadora con acondicionamiento de aire especial, con 
equipos de operadores profesionales para operarías. Sólo las grandes empresas, o las principales 
dependencias del gobierno o universidades, podían solventar el costo de muchos millones de dólares. Para 
ejecutar un trabajo (es decir, un programa o serie de programas), un programador escribía primero el 
programa en papel (en FORTRAN o ensamblador) y luego lo perforaba en taijetas. Después, llevaba el 
grupo de taijetas al cuarto de entrada y lo entregaba a uno de los operadores. 

Cuando la computadora terminaba el trabajo que estaba ejecutando en ese momento, un operador 
acudía a la impresora, separaba la salida impresa y la llevaba al cuarto de salida donde el 
programador podía recogerla después. Luego, el operador tomaba uno de los grupos de taijetas 
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traídos del cuarto de entrada y lo introducía en el lector. Si se requería el compilador de FORTRAN, el 
operador tenía que traerlo de un archivero e introducirlo en el lector. Gran parte del tiempo de 
computadora se desperdiciaba mientras los operadores iban de un lugar a otro, en el cuarto de la máquina. 

Dado el alto costo del equipo, no es sorprendente que la gente pronto buscara formas de reducir el 
desperdicio de tiempo. La solución que se adoptó generalmente fue el sistema por lotes. El principio 
de este modo de operación consistía en juntar una serie de trabajos en el cuarto de entrada, leerlos y 
grabarlos en una cinta magnética usando una computadora pequeña y (relativamente) económica, como 
una IBM 1401, que era muy buena para leer tarjetas, copiar cintas e imprimir salidas, pero no para realizar 
cálculos numéricos. Otras máquinas, mucho más costosas, como la IBM 7094, se usaban para la 
computación propiamente dicha. Esta situación se muestra en la Fig. 1-2. 



Figura 1-2. Uno de los primeros sistemas por lotes, (a) Los programadores traen tarictas a 
la 1401. (b) La 1401 lee lotes de trabajos y los graba en cinta, (c) El operador lleva lacinia de 
entrada a la 7094. (d) La 7094 realiza la computación, (c) El operador lleva la cinta de salida 
a la 1401. (0 La 1401 imprime la salida. 


Después de cerca de una hora de reunir un lote de trabajos, la cinta se rebobinaba y se llevaba al 
cuarto de la máquina, donde se montaba en una unidad de cinta. El operador cargaba entonces un 
programa especial (el antepasado del sistema operativo actual), que leía el primer trabajo de la cinta y lo 
ejecutaba. La salida se escribía en una segunda cinta, en lugar de imprimirse. Cada vez que terminaba un 
trabajo, el sistema operativo leía automáticamente el siguiente trabajo de la cinta y comenzaba a 
ejecutarlo. Una vez que estaba listo todo el lote, el operador desmontaba las cintas de entrada y salida, 
montaba la cinta de entrada del siguiente lote, y llevaba la cinta de salida a una 1401 para la impresión 
fuera de línea (o sea, no conectada a la computadora principal). 

La estructura de un trabajo de entrada típico se muestra en la Fig. 1-3. El trabajo comenzaba con una 
tarjeta $JOB, que especificaba el tiempo de ejecución máximo en minutos, el número de cuenta al que 
se debía cobrar el trabajo, y el nombre del programador. Luego venía una tarjeta $FORTRAN, 
que ordenaba al sistema operativo leer el compilador de FORTRAN de la cinta de sistema. Esta tarjeta 
iba seguida del programa por compilar y por una tarjeta $LOAD, que ordenaba al sistema 
operativo cargar el programa objeto recién compilado. (Los programas compilados a 
menudo se escribían en cintas temporales y tenían que cargarse explícitamente.) Luego venía la 
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taijeta $RUN, que ordenaba al sistema operativo ejecutar el programa con los datos que le se- guían. Por 
último, la tarjeta $END marcaba el fin al del trabajo. Estas tarjetas de control primitivas eran los 
precursores de los lenguajes de control de trabajos e intérpretes de comandos modernos. 



Las computadoras grandes de la segunda generación se usaban primordialmente para cálculos 
científicos y de ingeniería, como la resolución de ecuaciones diferenciales parciales. Estas máquinas 
generalmente se programaban en FORTRAN y lenguaje ensamblador. Los sistemas operativos típicos 
eran FMS (el Fortran Monitor System) e IBSYS, el sistema operativo de IBM para la 7094. 

1,2.3 La tercera generación (1965-1980): Circuitos integrados y multiprogramación 

A principios de la década de 1960, la mayoría de los fabricantes de computadoras tenían dos líneas 
de producto distintas y totalmente incompatibles. Por un lado estaban las computadoras científicas a gran 
escala, orientadas hacia las palabras, como la 7094, que se usaban para cálculos numéricos en ciencias e 
ingeniería. Por el otro, estaban las computadoras comerciales orientadas hacia los caracteres, como la 
1401, que los bancos y las compañías de seguros utilizaban amplia- mente para ordenar e imprimir desde 
cinta. 

La creación y manteni mi ento de dos líneas de producto totalmente distintas era una situación costosa 
para los fabricantes. Además, muchos clientes de computadoras nuevas necesitaban inicialmente una 
máquina pequeña que más adelante les resultaba insuficiente, de modo que querían una máquina más 
grande que ejecutara todos sus viejos programas, pero más rápidamente. 
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IBM trató de resolver simultáneamente ambos problemas introduciendo la System/360. La 360 era 
una serie de máquinas de software compatible que iban desde tamaños comparables a la 1401 hasta 
computadoras mucho más potentes que la 7094. Las máquinas diferían sólo en el precio y el rendimiento 
(memoria máxima, velocidad del procesador, número de dispositivos de E/S permitidos, etc.). Puesto 
que todas las máquinas tenían la misma arquitectura y conjunto de instrucciones, los programas escritos 
para una máquina podían ejecutarse en todas las demás, al menos en teoría. Además, la 360 estaba 
diseñada para manejar computación tanto científica como comercial. Así, una sola familia de máquinas 
podía satisfacer las necesidades de todos los clientes. En años subsecuentes IBM produjo sucesoras 
comparables a la línea 360, usando tecnología más moderna, conocidas como series 370, 4300, 3080 y 
3090. 

La 360 fue la primera línea importante de computadoras en usar (a pequeña escala) circuitos 
integrados (IC), ofreciendo así una ventaja de precio/rendimiento considerable respecto a las máquinas de 
la segunda generación, que se armaban con transistores individuales. Esta línea fue un éxito inmediato, y 
la idea de una familia de computadoras compatibles pronto fue adoptada por todos los demás fabricantes 
importantes. Los descendientes de estas máquinas todavía se emplean en uno que otro centro de cómputo 
en la actualidad, pero su uso está en rápido declive. 

La gran ventaja de la idea de “una familia” fue también su gran debilidad. La intención era que todo 
el software, incluido el sistema operativo, funcionara en todos los modelos. El software tenía que 
funcionar en sistemas pequeños, que en muchos casos simplemente sustituían a la 1401 para copiar 
taijetas en cinta, y en sistemas muy grandes, que con frecuencia sustituían a las 7094 para realizar 
pronósticos del tiempo y otros trabajos de computación pesada. El software tenía que ser bueno en 
sistemas con pocos y con muchos periféricos; tenía que funcionar en entornos comercia- les y. científicos 
y, sobre todo, tenía que ser eficiente para todos estos usos distintos. 

Era imposible que IBM (o alguien más) pudiera escribir un programa que satisficiera todos esos 
requisitos opuestos. El resultado fue un sistema operativo enorme, extraordinariamente complejo, tal vez 
dos o tres órdenes de magnitud mayor que FMS. Este sistema consistía en millones de líneas de 
lenguaje ensamblador escrito por miles de programadores, y contenía miles y miles de errores, 
requiriéndose un flujo continuo de nuevas versiones en un intento por corregirlos. Cada versión nueva 
corregía algunos errores e introducía otros nuevos, de modo que es probable que el número de errores se 
mantuviera constante con el tiempo. 

Uno de los diseñadores de OS/360, Fred Brooks, escribió después un ingenioso e incisivo libro 
(Brooks, 1975) describiendo sus experiencias con el OS/360. Aunque sería imposible resumir aquí ese 
libro, baste con decir que la portada muestra una manada de bestias prehistóricas atascadas en un foso de 
brea. La portada del libro de Silberschatz y Galvin (1994) es una alusión similar. 

A pesar de su enorme tamaño y de sus problemas, os/360 y los sistemas operativos de tercera 
generación parecidos a él producidos por otros fabricantes de computadoras lograron satisfacer a sus 
clientes en un grado razonable, y también popularizaron varias técnicas clave que no existían en 
los sistemas operativos de la segunda generación. Tal vez la más importante de ellas haya sido 
la multiprogramación. En la 7094, cuando el trabajo actual hacía una pausa para esperar que 
se completara una operación de cinta u otra operación de E/S, la CPU simplemente permanecía 
ociosa hasta que la E/S terminaba. En los cálculos científicos, con gran uso de CPU, la E/S es 
poco frecuente, así que el tiempo desperdiciado no es significativo. En el procesamiento de datos 
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comerciales, el tiempo de espera por E/S puede ser el 80090% del tiempo total, de modo que algo debía 
hacerse para evitar que la CPU estuviera ociosa tanto tiempo. 

La solución a la que se llegó fue dividir la memoria en varias secciones, con un trabajo distinto en 
cada partición, como se muestra en la Fig. 1-4. Mientras un trabajo estaba esperando que terminara su 
E/S, otro podía estar usando la CPU. Si se podían tener en la memoria principal suficientes trabajos a la 
vez, la CPU podía mantenerse ocupada casi todo el tiempo. Tener múltiples trabajos en la memoria a la 
vez requiere hardware especial para proteger cada trabajo contra espionaje o p por parte de los demás, 
pero la 360 y otros sistemas de tercera generación estaban equipados con este hardware. 


Sistema 

operativo 


Particiones 
de memoria 


Figura 1-4. Sistema de multiprogramación con tres trabajos en la memoria. 


Otra característica importante presente en los sistemas operativos de la tercera generación era la 
capacidad de leer trabajos de las tarjetas al disco tan pronto como se llevaban al cuarto de computadoras. 
Luego, cada vez que un trabajo terminaba su ejecución, el sistema operativo podía cargar uno nuevo del 
disco en la partición que había quedado vacía y ejecutarlo. Esta técnica se llama spooling (de “operación 
simultánea de periféricos en línea”) y también se usaba para la salida. Con spooling, las 1401 ya no eran 
necesarias, y desapareció una buena parte del transporte de cintas. 

Aunque los sistemas operativos de la tercera generación se adaptaban bien a cálculos científicos 
extensos y sesiones masivas de procesamiento de datos comerciales, seguían siendo básicamente sistemas 
por lotes. Muchos programadores añoraban los días de la primera generación cuando tenían toda la 
máquina para ellos solos durante unas cuantas horas, lo que les permitía depurar sus programas 
rápidamente. Con los sistemas de la tercera generación, el tiempo entre la presentación de un trabajo y la 
obtención de las salidas a menudo era de varias horas, y una sola coma mal colocada podía causar el 
fracaso de una compilación y que el programador desperdiciara medio día. 

Este deseo de respuesta rápida preparó el camino para el tiempo compartido, una variante de la 
multiprogramación, en la que cada usuario tiene una ter mi nal en línea. En un sistema de 
tiempo compartido, si 20 usuarios ingresan en el sistema y 17 de ellos están pensando, 
hablando o tomando café, la CPU puede asignarse por tumo a los tres trabajos que requieren 
servicio. Puesto que las personas que están depurando programas usualmente emiten comandos cortos 
(p. ej., compilar un procedimiento de cinco páginas) en vez de largos (p. ej., ordenar un archivo de un 
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millón de registros), la computadora puede proporcionar servicio rápido interactivo a varios usuarios y tal 
vez también trabajar con trabajos de lote grandes en segundo plano cuando la CPU está ociosa. Aunque el 
primer sistema serio de tiempo compartido (cTss) fue creado en el M.I.T. en una 7094 especialmente 
modificada (Corbato et al., 1962), el tiempo compartido no se popularizó realmente hasta que se 
generalizó el uso del hardware de protección necesario durante la tercera generación. 

Después del éxito del sistema CTSS, MIT, Bell Labs y General Electric (por ese entonces un 
fabricante importante de computadoras) decidieron emprender el desarrollo de un “servicio de 
computadora” una máquina que diera apoyo a cientos de usuarios de tiempo compartido simultáneos. Su 
modelo fue el sistema de distribución de electricidad: cuando usted necesita potencia eléctrica, 
simplemente enchufa una clavija en la pared y, dentro de límites razonables, obtendrá tanta electricidad 
como necesite. Los diseñadores de este sistema, llamado MULTICS (servicio de información y 
computación multiplexado), contemplaban una enorme máquina que proporcionara potencia de cómputo a 
todos los usuarios de Boston. La idea de que máquinas mucho más potentes que su GE-645 se vendieran 
como computadoras personales por unos cuantos miles de dólares sólo 30 años después no era sino ciencia 
ficción en ese entonces. 

Para resumir un poco la historia, MULTICS introdujo muchas ideas seminales en la literatura de 
computación, pero su construcción fue mucho más difícil de lo que nadie había imaginado. Bell Labs 
abandonó el proyecto, y General Electric dejó el negocio de las computadoras por completo. Linalmente, 
MULTICS funcionó lo bastante bien como para usarse en un entorno de producción de MIT y en docenas 
de otros sitios, pero el concepto de un servicio de computadora se hizo obsoleto al desplomarse los 
precios de las computadoras. No obstante, MULTICS tuvo una influencia enorme sobre los sistemas 
subsecuentes; se le describe en (Corbato et al., 1972; Corbato y Vyssotsky, 1965; Daley y Dermis, 1968; 
Organick, 1972; Saltzer, 1974). 

Otro avance importante durante la tercera generación fue el crecimiento fenomenal de las 
minicomputadoras, comenzando con la DEC PDP- 1 en 1961. La PDP- 1 sólo tenía 4K de palabras de 18 
bits, pero a $120 000 por máquina (menos del 5% del precio de una 7094), se vendieron como pan 
caliente. Para ciertos tipos de trabajos no numéricos, la PDP-1 era casi tan rápida como la 7094, e hizo 
nacer una industria totalmente nueva. A esta máquina pronto siguió una serie de Otras PDP (todas 
incompatibles, a diferencia de la familia IBM), culminando en la PDP- 11. 

Uno de los computólogos de Bell Labs que había trabajado en el proyecto MULTICS, Ken 
Thompson, encontró subsecuentemente una pequeña minicomputadora PDP-7 que nadie estaba usando y 
se propuso escribir una versión de MULTICS reducida al mínimo, para un solo usuario. Este trabajo 
posteriormente evolucionó para convertirse en el sistema operativo UNIX®, que se popularizó en el 
mundo académico, las dependencias del gobierno y muchas compañías. 

La historia de UNIX se cuenta en otras obras (p. ej., Salus, 1994). Baste con decir que, dado que casi 
todo mundo podía obtener el código fuente, diversas organizaciones desarrollaron sus propias versiones 
(incompatibles), lo que condujo al caos. Con objeto de que fuera posible escribir programas susceptibles 
de ejecución en cualquier sistema UNIX, el IEEE creó un estándar para UNIX, llamado posix, que casi 
todas las versiones actuales de UNIX reconocen. POSIX define una interfaz mínima de llamadas al 
sistema que los sistemas UNIX deben reconocer. De hecho, algunos otros sistemas de programación ya 
reconocen la interfaz POSIX. 
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1.2.4 La cuarta generación (1980-presente): 

Computadoras personales 

Con la invención de los circuitos integrados a gran escala (LSI), chips que contienen miles de transistores 
en un cm 2 de silicio, nació la era de la computadora personal. En términos de arquitectura, las 
computadoras personales no eran muy diferentes de las minicomputadoras de la clase PDP- 11, pero en 
términos de precio sí que eran diferentes. Si bien la minicomputadora hacía posible que un departamento 
de una compañía o universidad tuviera su propia computadora, el chip microprocesador permitía que un 
solo individuo tuviera su propia computadora personal. Las computadoras personales más potentes 
empleadas por empresas, universidades e instalaciones del gobierno suelen llamarse estaciones de 
trabajo, pero en realidad sólo son computadoras personales grandes. Por lo regular estas máquinas están 
interconectadas mediante una red. 

La amplia disponibilidad de la potencia de cómputo, sobre todo la potencia de cómputo alta- mente 
interactiva casi siempre acompañada por excelentes gráficos, dio pie al crecimiento de una importante 
industria productora de software para computadoras personales. Una buena parte de este software era 
amistoso con el usuario, lo que significa que estaba dirigido a usuarios que no sólo no sabían nada de 
computación, sino que además no tenían la mínima intención de aprender. Sin duda, esto representaba un 
cambio drástico respecto al os/360, cuyo lenguaje de control de trabajos, JCL, era tan arcano que llegaron 
a escribirse libros enteros sobre él (p. ej., Cadow, 1970). 

Dos sistemas operativos dominaron inicialmente el campo de las computadoras personales y las 
estaciones de trabajo: MS-DOS de Microsoft y UNIX. MS-DOS se usaba ampliamente en la IBM PC y 
otras máquinas basadas en la CPU Intel 8088 y sus sucesoras, la 80286, 80386 y 80486 (que en adelante 
llamaremos la 286, 386 y 486, respectivamente) y más tarde la Pentium y Pentium Pro. Aunque la 
versión inicial de MS-DOS era relativamente primitiva, versiones subsecuentes han incluido 
características más avanzadas, muchas de ellas tomadas de UNIX. El sucesor de Microsoft para MS-DOS, 
WINDOWS, originalmente se ejecutaba encima de MS-DOS (es decir, era más un shell que un verdadero 
sistema operativo), pero a partir de 1995 se produjo una versión autosuficiente de WINDOWS, 
WINDOWS 95®, de modo que ya no se necesita MS-DOS para apoyarlo. Otro sistema operativo de 
Microsoft es WINDOWS NT, que es compatible con WINDOWS 95 en cierto nivel, pero internamente se 
reescribió desde cero. 

El otro competidor importante es UNIX, que domina en las estaciones de trabajo y otras computadoras 
del extremo alto, como los servidores de red. UNIX es popular sobre todo en máquinas basadas en chips 
RISC de alto rendimiento. Estas máquinas por lo regular tienen la potencia de cómputo de una 
minicomputadora, a pesar de estar dedicadas a un solo usuario, por lo que resulta lógico que estén 
equipadas con un sistema operativo diseñado originalmente para minicomputadoras, a saber, UNIX. 

Una tendencia interesante que apareció a mediados de la década de 1980 fue el crecimiento de redes 
de computadoras personales en las que se ejecutan sistemas operativos de red o sistemas operativos 
distribuidos (Tanenbaum, 1995). En un sistema operativo de red los usuarios están conscientes de la 
existencia de múltiples computadoras y pueden ingresar en máquinas re -motas y copiar archivos de una 
máquina a otra. Cada máquina ejecuta su propio sistema operativo local y tiene su propio usuario o 
usuarios locales. 
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Los sistemas operativos de red no son fundamentalmente distintos de aquellos para un solo 
procesador. Obviamente, estos sistemas necesitan un controlador de la interfaz con la red y software de 
bajo nivel para operarlo, así como programas para realizar inicios de sesión remotos y acceso a archivos 
remotos, pero estas adiciones no alteran la estructura esencial del sistema operativo. 

Un sistema operativo distribuido, en cambio, presenta el mismo aspecto a los usuarios que un 
sistema tradicional de un solo procesador, aunque en realidad se compone de múltiples procesadores. Los 
usuarios no deben enterarse de en dónde se están ejecutando sus programas o almacenando sus archivos; 
de todo eso debe encargarse el sistema operativo automática y eficientemente. 

Los verdaderos sistemas operativos distribuidos requieren más que la adición de un poco más de 
código a un sistema operativo uniprocesador, porque los sistemas distribuidos y centralizados difieren en 
aspectos cruciales. Los sistemas distribuidos, por ejemplo, a menudo permiten a las aplicaciones 
ejecutarse en varios procesadores al mismo tiempo, por lo que requieren algoritmos de planificación de 
más complejos a fin de optimizar el grado de paralelismo. 

En muchos casos, los retardos de comunicación dentro de la red implican que éstos (y otros) 
algoritmos deban ejecutarse con información incompleta, caduca o incluso incorrecta. Esta situación 
difiere radicalmente un sistema de un solo procesador en el que el sistema operativo tiene toda la 
información sobré el estado del sistema. 


1,2.5 Historia de MINIX 

Cuando UNIX era joven (Versión 6), era fácil conseguir el código fuente, bajo licencia de AT&T, y se 
estudiaba mucho. John Lions, de la University of New South Wales en Australia, incluso escribió un 
librito que describía su operación, línea por línea (Lions, 1996). Este librito se usó (con permiso de 
AT&T) como texto en muchos cursos universitarios de sistemas operativos. 

Cuando AT&T liberó la Versión 7, comenzó a darse cuenta de que UNIX era un producto comercial 
valioso, así que entregó la Versión 7 junto con una licencia que prohibía el estudio del código fuente en 
cursos, a fin de evitar poner en peligro su situación de secreto comercial. Muchas universidades 
simplemente abandonaron el estudio de UNIX e impartieron sólo teoría. 

Desafortunadamente, cuando sólo se enseña teoría el estudiante adquiere una visión desbalanceada de 
cómo se ve realmente un sistema operativo. Los temas teóricos que suelen cubrirse con gran detalle en 
cursos y libros sobre sistemas operativos, como los algoritmos de planificación, en la práctica realmente 
no son tan importantes. Los temas que en verdad son relevantes, como E/S y sistemas de archivos, 
generalmente se descuidan porque no hay mucha teoría al respecto. 

A fin de remediar esta situación, uno de los autores de este libro (Tanenbaum) decidió escribir un 
nuevo sistema operativo desde cero que fuera compatible con UNIX desde el punto de vista del usuario, 
pero completamente distinto en su interior. Al no utilizar ni una sola línea del código de AT&T, 
este sistema evita las restricciones de la licencia, así que puede usarse en clase o para 
estudio individual, De esta forma, los lectores pueden disectar un sistema operativo real para ver 



14 


INTRODUCCIÓN 


CAP. 1 


qué hay dentro, tal como los estudiantes de biología disectan ranas. El nombre MINIX significa mini- 
UNIX porque es lo suficientemente pequeño como para poderlo entender a pesar de no ser un gurú. 

Además de la ventaja de eliminar los problemas legales, MINIX tiene otra ventaja respecto a UNIX: 
se escribió una década después de UNIX y tiene una estructura más modular. El sistema de archivos de 
MINIX, por ejemplo, no forma parte del sistema operativo, sino que se ejecuta como programa de usuario. 
Otra diferencia es que UNIX se diseñó de modo que fuera eficiente; MINIX se diseñó pensando en que 
fuera comprensible (hasta donde puede ser comprensible cualquier pro- grama que ocupa cientos de 
páginas). El código de MINIX, por ejemplo, incluye miles de comentarios. 

MINIX se diseñó originalmente de modo que fuera compatible con UNIX Versión 7 (V7). Se usó 
como modelo esta versión a causa de su sencillez y elegancia. A veces se dice que la Versión 7 no sólo 
representó una mejora respecto a sus predecesores, sino también respecto a todos sus sucesores. Con la 
llegada de POSIX, MINIX comenzó a evolucionar hacia el nuevo estándar, al tiempo que mantenía la 
compatibilidad hacia atrás con los programas existentes. Este tipo de evolución es común en la industria 
de las computadoras, pues ningún proveedor desea introducir un sistema nuevo que ninguno de sus 
clientes existentes podrá usar sin grandes convulsiones. La versión de MINIX Sue se describe en este 
libro se basa en el estándar POSIX (a diferencia de la versión descrita en la’ptimera edición, que se basaba 
en V7). 

Al igual que UNIX, MINIX se escribió en el lenguaje de programación C y se pretendía que fuera 
fácil transportarlo a diversas computadoras. La implementación inicial fue para la IBM PC, porque esta 
computadora se usa ampliamente. Subsecuentemente se llevó a las computadoras Atari, Amiga, 
Macintosh y SPARC. Acorde con la filosofía de que “lo pequeño es hermoso”, MINIX originalmente no 
requería siquiera un disco duro para ejecutarse, lo que lo ponía al alcance del presupuesto de muchos 
estudiantes (aunque puede parecer asombroso ahora, a mediados de la década de 1980 cuando MINIX vio 
por primera vez la luz, los discos duros aún eran una novedad de precio elevado). Al crecer MINIX en 
fúncionalidad y tamaño, llegó al punto en que se hizo necesario un disco duro, pero en concordancia con 
la filosofía de MINIX basta con una partición de 30 megahytes. En contraste, algunos sistemas UNIX 
comerciales ahora recomiendan una partición de disco de 200 MB como mínimo indispensable. 

Para el usuario medio sentado ante una IBM PC, ejecutar MINIX es similar a ejecutar UNIX. Muchos 
de los programas básicos, como cat, grep, is, make y el shell están presentes y desempeñan las mismas 
funciones que sus contrapartes de UNIX. Al igual que el sistema operativo mismo, todos estos programas 
de utilería fúeron reescritos completamente desde cero por el autor, sus estudiantes y algunas otras 
personas dedicadas. 

En todo este libro se usará MINIX como ejemplo. No obstante, casi todo lo que se diga acerca de 
MINIX, a menos que se refiera al código en sí, también aplica a UNIX. Muchos de estos comentarios 
también aplican a otros sistemas. Esto debe tenerse siempre presente al leer el libro. 

Como acotación, es posible que unas cuantas palabras acerca de LINUX y su relación con MINIX 
sean de interés para algunos lectores. Poco después de liberarse MINIX, se formó un grupo de 
noticias de USENET para hablar de él. En pocas semanas, este grupo tenía 40000 suscriptores, 
la mayor parte de los cuales quería agregar enormes cantidades de nuevas capacidades a MINIX a 
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fin de hacerlo más grande y mejor (bueno, al menos más grande). Cada día, varios cientos de ellos 
ofrecían sugerencias, ideas y fragmentos de código. El autor de MINIX resistió con éxito esta arremetida 
durante varios años, a fin de mantener a MINIX lo suficientemente pequeño y aseado como para que los 
estudiantes lo entendieran. Gradualmente, la gente comenzó a convencerse de que su posición era 
inamovible. Finalmente, un estudiante finlandés, Linus Torvalds, decidió escribir un clon de MINIX que 
pretendía ser un sistema de producción con abundantes capacidades, más que una herramienta educativa. 
Así fue como nació LINUX. 


1.3 CONCEPTOS DE SISTEMAS OPERATIVOS 

La interfaz entre el sistema operativo y los programas de usuario está definida por el conjunto de 
“operaciones extendidas” que el sistema operativo ofrece. Estas instrucciones se han llamado 
tradicionalmente llamadas al sistema, aunque ahora pueden implementarse de varias formas. Para 
entender realmente lo que los sistemas operativos hacen, debemos examinar con detenimiento esta 
interfaz. Las llamadas disponibles en la interfaz varían de un sistema operativo a otro (aunque los 
conceptos subyacentes tienden a ser similares). 

Por tanto, nos vemos obligados a escoger entre (1) generalidades vagas (“los sistemas operativos 
tienen llamadas al sistema para leer archivos”) y (2) algún sistema específico (“MINIX tiene una llamada 
al sistema READ) con tres parámetros: uno para especificar el archivo, uno para indicar dónde deben 
colocarse los datos y uno para indicar cuántos bytes deben leerse”) 

Hemos escogido el segundo enfoque. Esto implica más trabajo, pero nos permite entender mejor qué 
es realmente lo que hacen los sistemas operativos. En la sección 1.4 examinaremos de cerca las llamadas 
al sistema presentes tanto en UNIX como en MINIX. Por sencillez, sólo nos referiremos a MINIX, pero 
las llamadas al sistema UNIX correspondientes se basan en POSIX en la mayor parte de los casos. Sin 
embargo, antes de estudiar las llamadas al sistema reales, vale la pena presentar un panorama 

general de MINIX, a fin de tener una idea global de qué es lo que hace un sistema operativo. Este 
panorama aplica igualmente bien a UNIX. 

Las llamadas al sistema de MINIX pertenecen a dos categorías amplias: las que se ocupan de los 
procesos y las que se ocupan del sistema de archivos. A continuación las examinaremos por tumo. 


1.3.1 Procesos 

Un concepto clave en MINIX, y en todos los sistemas operativos, es el proceso. Un proceso es 
básicamente un programa en ejecución. Cada proceso tiene asociado un espacio de direcciones, una lista 
de posiciones de memoria desde algún mínimo (usualmente O) hasta algún máximo, que el proceso puede 
leer y escribir. El espacio de direcciones contiene el programa ejecutable, los datos del programa, y su 
pila. A cada proceso también se asocia un conjunto de registros, que incluyen el contador del programa, el 
apuntador de la pila y otros registros de hardware, así como toda la demás información necesaria para 
ejecutar el programa. 



16 


INTRODUCCIÓN 


CAP. 1 


Volveremos al concepto de proceso con mucho mayor detalle en el capítulo 2, pero por ahora la 
forma más fácil de adquirir una idea intuitiva de lo que es un proceso es pensar en los sistemas de tiempo 
compartido. Periódicamente, el sistema operativo decide dejar de ejecutar un proceso y comenzar a 
ejecutar otro, por ejemplo, porque el primero ya tuvo más tiempo de CPU del que le tocaba durante el 
segundo anterior. 

Cuando un proceso se suspende temporalmente de esta manera, debe reiniciarse después en el 
mismo estado exactamente en que estaba en el momento en que se le detuvo. Esto implica que toda la 
información acerca del proceso se debe guardar explícitamente en algún lugar durante la suspensión. Por 
ejemplo, es posible que el proceso tenga varios archivos abiertos para lectura. Cada uno de estos archivos 
tiene asociado un apuntador que indica la posición actual (es decir, el número del byte o registro que se 
leerá a continuación). Cuando un proceso se suspende temporalmente, es necesario guardar todos estos 
apuntadores para que una llamada READ ejecutada después de reiniciarse el proceso lea los datos 
correctos. En muchos sistemas operativos, toda la inform a ción acerca de cada proceso, aparte del 
contenido de su propio espacio de direcciones, se almacena en una tabla del sistema operativo llamada 
tabla de procesos, que es un arreglo (o lista enlazada) de estructuras, una para cada proceso existente en 
ese momento. 

Así, un proceso (suspendido) consiste en su espacio de direcciones, por lo regular llamado imagen de 
núcleo (recordando las memorias de núcleos magnéticos que se usaban en el pasado), y su entrada en la 
tabla de procesos, que contiene sus registros, entre otras cosas. 

Las llamadas al sistema de administración para procesos clave son las que se ocupan de la creación y 
terminación de procesos. Consideremos un ejemplo representativo. Un proceso llamado intérprete de 
comandos o Shell lee comandos de una terminal. El usuario acaba de teclear un comando solicitando la 
compilación de un programa. El shell debe crear ahora un proceso nuevo que ejecute el compilador. 
Cuando ese proceso haya terminado la compilación, ejecutará una llamada al sistema para terminarse a sí 
mi s mo. 

Si un proceso puede crear uno o más procesos distintos (denominados procesos hijos) y éstos a su 
vez pueden crear procesos hijos, pronto llegamos a la estructura de árbol de procesos de la Fig. 1-5. Los 
procesos relacionados que están cooperando para realizar alguna tarea a menudo necesitan comunicarse 
entre sí y sincronizar sus actividades. Esta comunicación se llama comunicación entre procesos, y se 
estudiará con detalle en el capítulo 2. 



Figura 1-5. Un árbol de procesos. El proceso <4 creó dos procesos hijos. B y C El proceso B 
creó ires procesos hijos. D.EyF. 
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Hay otras llamadas al sistema relacionadas con procesos que solicitan más memoria (o liberan 
memoria no utilizada), esperan que un proceso hijo termine, y superponen otro programa al suyo. 

Ocasionalmente, se hace necesario comunicar información a un proceso en ejecución que no está 
simplemente esperando recibirla. Por ejemplo, un proceso que se comunica con otro proceso en una 
computadora distinta lo hace enviando mensajes por una red. A fin de prevenir la posibilidad de que un 
mensaje o su respuesta se pierda, el remitente puede solicitar que su propio sistema operativo le notifique 
cuando haya transcurrido cierto número de segundos, a fin de poder re- transmitir el mensaje si todavía no 
ha llegado un acuse de recibo. Después de establecer este temporizador, el programa puede seguir 
realizando otros trabajos. 

Cuando ha transcurrido el número de segundos que se especificó, el sistema operativo envía una 
señal al proceso. La señal hace que el proceso suspenda temporalmente lo que estaba haciendo, guarde sus 
registros en la pila, y comience a ejecutar un procedimiento especial de manejo de señales, por ejemplo, 
para retrans mi tir un mensaje que al parecer se perdió. Una vez que el manejador de señales termina, el 
proceso en ejecución se reinicia en el estado en que estaba justo antes de la señal. Las señales son el 
análogo en software de las interrupciones de hardware, y pueden ser generadas por diversas causas 
además de la expiración de temporizadores. Muchas trampas detectadas por el hardware, como la 
ejecución de una instrucción no permitida o el empleo de una dirección no válida, también se convierten 
en señales que se envían al proceso culpable. 

El administrador del sistema asigna un uid (identificador de usuario) a cada persona autorizada para 
usar MINIX. Cada proceso iniciado en MINIX tiene el uid de la persona que lo inició. Un proceso hijo 
tiene el mismo uid que su padre. Un uid, llamado superusuario, tiene facultades especiales, y puede 
violar muchas de las reglas de protección. En las instalaciones grandes, sólo el administrador del 
sistema conoce la contraseña necesaria para convertirse en superusuario, pero muchos de los usuarios 
ordinarios (sobre todo estudiantes) dedican un esfuerzo considerable a tratar de encontrar defectos en el 
sistema que les permitan convertirse en superusuarios sin contar con la contraseña. 


1.3.2 Archivos 

La otra categoría amplia de llamadas al sistema se relaciona con el sistema de archivos. Como ya se 
apuntó, una fúnción importante del sistema operativo es ocultar las peculiaridades de los discos y otros 
dispositivos de E/S y presentar al programador un modelo abstracto, aseado y bonito, de archivos 
independientes del dispositivo. Es obvio que se necesitan llamadas al sistema para crear, eliminar, leer y 
escribir archivos. Antes de que un archivo pueda leerse, debe abrirse, y después de leerse debe cerrarse, 
así que también se incluyen llamadas para hacer estas cosas. 

A fin de contar con un lugar para guardar los archivos, MINIX tiene el concepto de directorio como 
mecanismo para agrupar los archivos. Un estudiante, por ejemplo, podría tener un directorio para 
cada curso en el que está inscrito (donde guardaría los programas necesarios para ese curso), 
otro directorio para su correo electrónico, y otro más para su página base de la World 
Wide Web. Por tanto, se necesitan llamadas al sistema para crear y eliminar directorios. También 
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se incluyen llamadas para poner un archivo existente en un directorio, y para quitar un archivo de un 
directorio. Las entradas de directorio pueden ser archivos u otros directorios. Este modelo también da pie 
a una jerarquía —el sistema de archivos— como se muestra en la Fig. 1-6. 


Directorio raíz 



Las jerarquías de procesos y de archivos están organizadas como árboles, pero hasta ahí llega la 
similitud. Las jerarquías de procesos no suelen ser muy profundas (casi nunca tienen más de tres 
niveles), en tanto que las de archivos comú nm ente tienen cuatro, cinco o incluso más niveles de 
profundidad. Las jerarquías de procesos por lo regular tienen una vida corta, generalmente de unos 
cuantos minutos como máximo, en tanto que la jerarquía de directorios podría existir durante años. La 
propiedad y protección también es diferente para los procesos y para los archivos. Típicamente, sólo un 
proceso padre puede controlar o incluso acceder a un proceso hijo, pero casi siempre existen mecanismos 
para permitir que los archivos y directorios sean leídos por un grupo más amplio que sólo el propietario. 

Cada archivo dentro de la jerarquía de directorios se puede especificar dando su nombre de ruta a 
partir del tope de la jerarquía de directorios, el directorio raíz. Semejantes nombres de ruta absolutos 
consisten en la lista de directorios por los que se debe pasar partiendo del directorio raíz para llegar al 
archivo, separando los componentes con diagonales. En la Fig. 1-6, la ruta del archivo CSJOJ es IP 
rofesorado/P rof Ruiz/Cursos/CSJOJ. La diagonal inicial indica que la ruta es absoluta, es decir, que 
comienza en el directorio raíz. 

En todo momento, cada proceso tiene un directorio de trabajo actual, en el cual se buscan 
los archivos cuyos nombres de ruta no comienzan con una diagonal. Por ejemplo, en la Fig. 1-6, 
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si /Profesorado/Prof Ruiz fuera el directorio de trabajo, el empleo del nombre de ruta Cursos/ CSJOI se 
referiría al mismo archivo que el nombre de ruta absoluta dado en el párrafo anterior. Los procesos 
pueden cambiar de directorio de trabajo emitiendo una llamada al sistema que especifique el nuevo 
directorio de trabajo. 

Los archivos y directorios en MINIX se protegen asignando a cada uno un código de protección 
binario de 9 bits. El código de protección consiste en tres campos de 3 bits, uno para el propietario, uno 
para otros miembros del grupo del propietario (el administrador del sistema divide a los usuarios en 
grupos) y uno para toda la demás gente. Cada campo tiene un bit para acceso de lectura, uno para acceso 
de escritura y uno para acceso de ejecución. Estos tres bits se conocen como bits rwx. Por ejemplo, el 
código de protección rwxr-x—x significa que el propietario puede leer, escribir o ejecutar el archivo, otros 
miembros del grupo pueden leer o ejecutar (pero no escribir) el archivo, y el resto de la gente puede 
ejecutar (pero no leer ni escribir) el archivo. En el caso de un directorio, x indica permiso de búsqueda. Un 
guión significa que el permiso correspondiente está ausente. 

Antes de poder leer o escribir un archivo, es preciso abrirlo, y en ese momento se verifican los 
permisos. Si está permitido el acceso, el sistema devuelve un entero pequeño llamado descriptor de 
archivo que se usará en operaciones subsecuentes. Si el acceso está prohibido, se devuelve un código de 
error. 

Otro concepto importante en MINIX es el de sistema de archivos montado. Casi todas las 
computadoras personales tienen una o más unidades de disco flexible en las que pueden insertarse y de 
las que pueden retirarse disquetes. A fin de contar con una forma congruente de manejar estos medios 
removibles (y también los CD-ROM, que también son removibles), MINIX permite conectar el sistema de 
archivos del disco flexible al árbol principal. Considere la situación de la Fig. l-7(a). Antes de la llamada 
MOUNT, el disco en RAM (disco simulado en la memoria principal) contiene el sistema de archivos 
raíz, o primario, y la unidad O contiene un disquete que contiene otro sistema de archivos. 



(a) «» 

Figura 1-7. (a) Antes de montarse, los archivos de la unidad 0 no están accesibles. (b> Des¬ 
pués de montarse, esos archivos forman parte de la jerarquía de archivos. 


Sin embargo, no podemos usar el sistema de archivos de la unidad O, porque no hay forma de 
especificar nombres de ruta en él. MINIX no permite anteponer a los nombres de ruta un nombre o 
número de unidad; ésa sería precisamente la clase de dependencia del dispositivo que los sistemas 
operativos deben eliminar. En vez de ello, la llamada al sistema MOUNT permite conectar el sistema 
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de archivos de la unidad O al sistema de archivo raíz en cualquier lugar en el que el programa quiera que 
esté. En la Fig. l-7(b) el sistema de archivos de la unidad O se montó en el directorio h, permitiendo así 
el acceso a los archivos /b/x y Ib/y. Si el directorio b hubiera contenido archivos, éstos no habrían estado 
accesibles mientras estuviera montada la unidad O, ya que Ib se habría referido al directorio raíz de la 
unidad O. (No poder acceder a esos archivos no es tan grave como parece a primera vista: los sistemas de 
archivos casi siempre se montan en directorios vacíos.) 

Otro concepto importante en MINIX es el archivo especial. Los archivos especiales sirven para 
hacer que los dispositivos de E/S semejen archivos. Así, esos dispositivos pueden leerse y escribirse 
usando las mismas llamadas al sistema que se usan para leer y escribir archivos. Existen dos tipos de 
archivos especiales: archivos especiales por bloques y archivos especiales por caracteres. Los primeros 
se usan para modelar dispositivos que consisten en una colección de bloques directamente direccionables, 
como los discos. Al abrir un archivo especial por bloques y leer, digamos, el bloque 4, un programa puede 
acceder directamente al bloque 4 del dispositivo, pasando por alto la estructura del sistema de archivos 
que contiene. De forma similar, los archivos especiales por caracteres se usan para modelar impresoras, 
módems y otros dispositivos que aceptan o producen flujos de caracteres. 

La última característica que mencionaremos en esta reseña general se relaciona tanto con los procesos 
como con los archivos: los conductos. El conducto es una especie de seudoarchivo que puede servir para 
conectar dos procesos, como se muestra en la Fig. 1-8. Cuando el proceso A desea enviar datos al proceso 
B, escribe en el conducto como si fuera un archivo de salida. El proceso B puede leer los datos leyendo 
del conducto como si fuera un archivo de entrada. Así, la comunicación entre procesos en MINIX se 
parece mucho a las lecturas y escrituras de archivos normales. Es más, la única forma en que un proceso 
puede descubrir que el archivo de salida en el que está escribiendo no es realmente un archivo, sino un 
conducto, es emitiendo una llamada especial al sistema. 


O Conducto /"‘""N 

=—(£> 

Figura 1-8. Dos procesos conectados por un conducto. 


1.3.3 El shell 

El sistema operativo MINIX es el código que ejecuta las llamadas al sistema. Los editores, compiladores, 
ensambladores, vinculadores e intérpretes de comandos definitivamente no forman parte del sistema 
operativo, aunque son importantes y útiles. A riesgo de confúndir un poco las cosas, en esta 
sección examinaremos brevemente el intérprete de comandos de MINIX, llamado shell, que, si bien 
no es parte del sistema operativo, utiliza intensivamente muchas de las características 
del sistema operativo y, por tanto, es un buen ejemplo de la forma en que pueden usarse 
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las llamadas al sistema. El shell también es la interfaz primaria entre un usuario sentado ante su terminal y 
el sistema operativo. 

Cuando un usuario ingresa en el sistema, se inicia un shell. El shell tiene la terminal como entrada 
estándar y salida estándar, y lo primero que hace es exhibir la indicación (prompt ), un carácter como un 
signo de dólar, que le indica al usuario que el shell está esperando para aceptar un comando. Si el usuario 
ahora teclea 

date 

por ejemplo, el shell crea un proceso hijo y ejecuta el programa date como hijo. Mientras se está 
ejecutando el proceso hijo, el shell espera a que ter mi ne. Cuando el hijo termina, el shell exhibe otra vez 
la indicación y trata de leer la siguiente línea de entrada. 

El usuario puede especificar que la salida estándar sea redirigida a un archivo, por ejemplo, 

date >archivo 

De forma similar, la entrada estándar puede redirigirse, como en 
sort <archivo 1 >archivo2 

que invoca el programa sort con entradas tomadas de archivol y enviando las salidas a archivo2. 

La salida de un programa puede usarse como entrada para otro programa conectándolos con 
un conducto Así, 

cat archivol archivo2 archivo3 1 sort >/dev/Ip 

invoca el programa cat para concatenar tres archivos y enviar la salida a son para que acomode todas las 
líneas en orden alfabético. La salida de son se redirige al archivo /dev/lp, que es un nombre típico para el 
archivo especial por caracteres de la impresora. (Por convención, todos los archivos especiales se guardan 
en el directorio /dev.) 

Si un usuario escribe un signo & después de un comando, el shell no espera hasta que se completa, 
sino que exhibe una indicación de inmediato. Por tanto, 

cat archivol archivo2 archivo3 1 sort >/dev/lp & 

inicia el ordenamiento como trabajo de segundo plano, permitiendo que el usuario siga trabajan- do 
normalmente mi entras se está realizando el ordenamiento. El shell tiene varias otras características 
interesantes que no tenemos espacio para examinar aquí. Consulte cualquiera de las referencias sugeridas 
sobre UNIX si desea más información acerca del shell. 


1.4 LLAMADAS AL SISTEMA 

Armados con nuestro conocimiento general de cómo MINIX maneja los procesos y los archivos, ahora 
podemos comenzar a examinar la interfaz entre el sistema operativo y sus programas de aplicación, 
es decir, el conjunto de llamadas al sistema. Si bien esta explicación se refiere 
específicamente a posix (Norma Internacional 9945-1), y por tanto también a MINIX, casi todos 
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los sistemas operativos modernos tienen llamadas al sistema que realizan las mismas funciones, aunque 
los detalles sean diferentes. Puesto que el mecanismo real de la emisión de una llamada al sistema 
depende mucho de la máquina, y a menudo debe expresarse en código de ensamblador, se proporciona 
una biblioteca de procedimientos que permite efectuar llamadas al sistema desde programas en C. 

A fin de hacer más claro el mecanismo de las llamadas al sistema, examinemos brevemente READ 
(leer) Esta llamada tiene tres parámetros: el primero especifica el archivo, el segundo especifica el buffer, 
y el tercero especifica el número de bytes por leer. Una llamada de READ desde un programa en C podría 
verse así: 

cuenta = read(file, buffer, nbytes); 

La llamada al sistema (y el procedimiento de biblioteca) devuelve en cuenta el número de bytes que 
realmente se leyeron. Este valor normalmente es igual a nbytes, pero puede ser menor, si, por ejemplo, se 
llega al fin del archivo durante la lectura. 

Si la llamada al sistema no puede ejecutarse, ya sea a causa de un parámetro no válido o de un error de 
disco, se asignará el valor —1 a cuenta, y el número del error se colocará en una variable global, ermo. 
Los programas siempre deben revisar los resultados de una llamada al sistema para ver si ocurrió un error. 

MINIX tiene un total de 53 llamadas al sistema, las cuales se listan en la Fig. 1-9, agrupadas por 
comodidad en sE/S categorías. En las siguientes secciones examinaremos brevemente cada una de estas 
llamadas para ver qué hacen. En gran medida, los servicios que estas llamadas ofrecen determinan la 
mayor parte de lo que el sistema operativo tiene que hacer, ya que la administración de recursos en las 
computadoras personales es mínima (al menos comparada con las máquinas grandes que tienen muchos 
usuarios). 

Como acotación, vale la pena señalar que lo que constituye una llamada al sistema está abierto a 
interpretación. El estándar pos especifica varios procedimientos que un sistema que se ajuste a él debe 
proporcionar, pero no especifica si se trata de llamadas al sistema, llamadas de biblioteca o algo 

más. En algunos casos, los procedimientos PO se ofrecen como rutinas de biblioteca en MINIX. En otros, 
varios procedimientos requeridos son sólo variaciones menores de un procedimiento, y una llamada al 
sistema se encarga de todos ellos. 


1.4.1 Llamadas al sistema para administración de procesos 

El primer grupo de llamadas se ocupa de la administración de procesos. FORK (bifúrcar) es un buen lugar 
para iniciar la explicación. FORK es la única forma de crear un proceso nuevo. Esta llamada crea un 
duplicado exacto del proceso original, incluidos todos los descriptores de archivo, registros... todo. 
Después del FORK, el proceso original y la copia (el padre y el hijo) siguen cada quien su camino. 
Todas las variables tienen valores idénticos en el momento del FORK, pero dado que los datos 
del padre se copian para crear el hijo, los cambios subsecuentes en uno de ellos no afectan 
al otro. (El texto, que es inmutable, es compartido entre padre e hijo.) La llamada FORK 
devuelve un valor, que es cero en el hijo e igual al identificador de proceso o pid del hijo en el 
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Administración de procesos pid > forki) 

pid = waitpidtpid, &siatloc. optsi 

s > waiti&status) 

s • execvctnamc. argv. envp) 

exift status) 

size = brd(addr) 

pid = gclpidí) 

pid = gelpgrpt i 

pid = selsid() 

I - ptracelrcq. pid. addr. data) 

Señale» s - sigactioní sig. &act. &oldact) 

s «sigretumt&context) 
s« sigprocmaskíhow. ókset. &old) 
s = sigpcndinglscl) 
s = sigsoxpeadisigmask) 
s = kilKpid. sig) 
residual = alarm(seconds) 
s = pausd) 

Administración de archivas fd = crcatiname. mode) 

td = mknodtnamc. mode. addr) 
fd = opcnlfile. how,...) 
s-closctfd) 

n • readifd. buffer, nkytcs) 
n = wntfUd. buffer. nbytes) 
pos = Iscektfd. offset, whence) 
s = slal(name. Sbuf) 
s - futan fd. &buf) 
td > dupffd) 

s - pipe4&fd|0|) 
s = iuciltíd. request. argp) 
s = atccsslname. amodc) 
s »renametold. ncw) 
s = Icnllltd. cmd....) 

Administración de directorios s « mkdirlnamc. mode) 

y sistemas de archivos s = rmdir(name) 

s = linkinamel. aame2) 
ss unlinklnamc) 
s * mountlspecial, ñame, ilag) 
s = umount(special) 

s = chdirt (límame) 
s chrootldóname) 

Protección s = chmodf ñame, model 

uid = ge1uidO 
gid = gctgido 
s > setgid(gid) 
s = sctgWCgld) 

s = chowntname. owner. group) 
oldma.sk = umask(complmode) 

Administración del liempo scconds = nmet&second») 

s - stime(tp) 
s = utimelfile. tíniep) 
s • timesibufferl 


Crea un proceso hijo idéntico al padre 

Espera que un hijo termine 

Versión vieja de waitpid 

Sustituye la imagen en memoria de un proceso 

Termina la ejecución de un proceso y devolver su estado 

Fija el tamaño del segmento de datos 

Devuelve el identificador de proceso del invocador 

Devuelve el identificador del grupo de procesos del revocador 

Crea una nueva sesión y devolver su identificador de grupo de procesos 

Se usa para depurar 

Define la acción a emprender al recibir señales 

Regresa de una señal 

Examina o cambia la máscara de señal 

Obtiene el conjunto de señales bloqueadas 

Sustituye la máscara de señal y suspende el proceso 

Envía una señal a un proceso 

Pone la alarma del reloj 

Suspende el invocador hasta la siguiente señal 

Forma obsoleta de crear un archivo nuevo 

Crea un nodo-i normal, especial o de directorio 

Abre un archivo para leer, escribir o ambas cosas 

Cierra un archivo abierto 

Lee datos de un archivo colocándolos en un buffer 

Escribe datos de un buffer a un archivo 

Mueve el apuntador de archivos 

Obtiene la información de estado de un archivo 

Obtiene la información de estado de un archivo 

Asigna un nuevo descriptor de archivo a un archivo abierto 

Crea un conducto 

Realiza operaciones especiales con un archivo 

Verifica la accesibilidad de un archivo 

Da a un archivo un nuevo nombre 

Bloqueo de archivos y otras operaciones 

Crea un directorio nuevo 

Elimina un directorio vacio 

Crea una nueva entrada. nairu-2. que apunta a ñame I 

Elimina una entrada de directorio 

Monta un sistema de archivos 

Desmonta un sistema de archivos 

Desaloja todos los bloques en caché al disco 

Cambia el directorio de trabajo 

Cambia el directorio raíz 

Cambia los bits de protección de un archivo 

Obtiene el uid del invocador 

Obtiene el gid del invocador 

Establece el uid del invocador 

Establece el gid del invocador 

Cambia el propietario y el grupo de un archivo 

Cambia la máscara de modo 

Obtiene el liempo transcurrido desde el lo. de enero de 1970 
Establece el liempo transcurrido desde el lo. de enero de 1970 
Establece el tiempo de "ultimo acceso" de un archivo 
Obtiene los tiempos de usuario y sistema gastados hasta el momento 


Figura 1-9. Las llamadas al sistema de MINIX. El código de retorno s es -I si ocurre un 
error: fd es un descriptor de archivo, y n es una cuenta de bytes. Los demás códigos de 
retorno son lo que el nombre sugiere. 
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proceso padre. Con base en el pid devuelto, los dos procesos pueden saber cuál es el proceso padre y cuál 
es el proceso hijo. 

En la mayor parte de los casos, después de un FORK, el hijo tendrá que ejecutar código diferente del 
de su padre. Considere el caso del shell. Éste lee un comando de la terminal, bifurca un proceso hijo, 
espera que el hijo ejecute el comando, y luego lee el siguiente comando cuando el hijo termina. Para 
esperar a que el hijo termine, el padre ejecuta una llamada al sistema WAITPID (esperar PID), que 
simplemente espera hasta que el hijo ter mi na (cualquier hijo si existe más de uno). WAITPID puede 
esperar un hijo específico, o cualquier hijo si se asigna -1 al primer parámetro. Cuando WAITPID termina, 
se asignará el valor de la situación de salida (terminación normal o anormal y valor de salida) del hijo a la 
dirección a la que apunta el segundo parámetro. Se ofrecen también varias otras opciones. La llamada 
WAITPID sustituye a la llamada anterior WAIT que ahora es obsoleta pero se incluye por razones de 
compatibilidad hacia atrás. 

Consideremos ahora la forma en que el shell usa FORK. Cuando se teclea un comando, el shell 
bifurca un nuevo proceso. Este proceso hijo debe ejecutar el comando del usuario, cosa que hace 
utilizando la llamada al sistema EXEC (ejecutar), que hace que toda su imagen de núcleo sea sustituida 
por el archivo nombrado en su primer parámetro. En la Fig. l-lo se muestra un shell muy simplificado 
que ilustra el uso de FORK, WAITPID y EXEC. 


wtiile (TRUE) { r repetir siempre 7 

read_command(command, parameters); f* leer entrada de la terminal 7 


¡f(fork() != 0) { /* bifurcar proceso hijo */ 

/* Código del padre. 7 

waitpid(-1, &status, 0); r esperar que el hijo salga 7 

}else{ 

/* Código del hijo. 7 

execve(command, parameters. 0): T ejecutar comando 7 

} 

} 


Figura 1-10. Un shell reducido al mínimo. En rodo este libro, se supone que TRUE es por 
definición I. 


En el caso más general, EXEC tiene tres parámetros: el nombre del archivo que se va a ejecutar, un 
apuntador al arreglo de argumentos y un apuntador al arreglo de entorno. Éstos se describirán en breve. Se 
proporcionan diversas rutinas de biblioteca, incluidas execi, execv, execle y execve que permiten omitir 
los parámetros o especificarlos de diversas formas. En todo este libro usaremos el nombre EXEC para 
representar la llamada al sistema invocada por todas estas rutinas. 

Consideremos el caso de un comando como 

cp archivol archivo2 

que sirve para copiar archivo] en archivo2. Una vez que el shell ha bifurcado, el proceso hijo localiza y 
ejecuta el archivo cp y le pasa los nombres de los archivos de origen y destino. 
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El programa principal de cp (y el de casi todos los demás programas) contiene la declaración 
main(argc, argv, envp) 

donde argc es una cuenta del número de elementos que hay en la línea de comandos, incluido el nombre 
del programa. Para el ejemplo anterior, argc es 3. 

El segundo parámetro, argv, es un apuntador a un arreglo. El elemento i de ese arreglo es un 
apuntador a la i-ésima cadena de la línea de comandos. En nuestro ejemplo, argv apuntaría a la cadena 
“cp”. De forma similar, argv apuntaría a la cadena de 5 caracteres “archivo 1”, y argv[2] apuntaría a la 
cadena de 5 caracteres “archivo2”. 

El tercer parámetro de main, envp, es un apuntador al entorno, un arreglo de cadenas que contienen 
asignaciones de la forma nombre = valor y que sirve para pasar a un programa información como el tipo 
de ter mi nal y el nombre del directorio base. En la Fig. l-lo no se pasa un entorno al hijo, así que el 
tercer parámetro de execve es un cero. 

Si EXEC parece complicado, no se desanime; ésta es la llamada al sistema más compleja. Todas las 
demás son mucho más sencillas. Como ejemplo de llamada sencilla, considere EXIT (salir), que los 
procesos deben usar al terminar de ejecutarse. EXIT tiene un solo parámetro, el estado de salida (O a 255), 
que se devuelve al padre en la variable status de la llamada al sistema WA1T o WAITPID. El byte de 
orden bajo de status contiene el estado de terminación, siendo O la terminación normal, y los demás 
valores, diversas condiciones de error. El byte de orden alto contiene el estado de salida del hijo (O a 255). 
Por ejemplo, si un proceso padre ejecuta la instrucción 

n = waitpid(—1, &status, options); 

se suspenderá hasta que algún proceso hijo termine. Si el hijo sale con, digamos, 4 como parámetro de 
exit, el padre será despertado después de asignarse el pid del hijo a n y 0x0400 a status. (En todo este 
libro se usará la convención de C de anteponer Ox a las constantes hexadecimales.) 

Los procesos en MINIX tienen su memoria dividida en tres segmentos: el segmento de texto (esto es, 
el código de programa), el segmento de datos (es decir, las variables) y el segmento de pila. El segmento 
de datos crece hacia arriba y el de pila lo hace hacia abajo, como se muestra en la Fig. 1-11. Entre ellos 
hay una brecha de espacio de direcciones no utilizado. La pila crece hacia la brecha automáticamente, 
según se necesite, pero la expansión del segmento de datos se efectúa explícitamente usando la llamada al 
sistema BRK. BRK tiene un parámetro, que da la dirección donde debe ter mi nar el segmento de datos. 
Esta dirección puede ser mayor que el valor actual (el segmento de datos está creciendo) o menor (el 
segmento de datos se está encogiendo). Desde luego, el parámetro debe ser menor que el apuntador de la 
pila, pues de otro modo los segmentos de datos y de pila se traslaparían, cosa que está prohibida. 

Para comodidad del programador, se ofrece una rutina de biblioteca sbrk que también cambia el 
tamaño del segmento de datos, sólo que su parámetro es el número de bytes por agregar a dicho segmento 
(un parámetro negativo reduce el tamaño del segmento de datos). Esta rutina opera siguiendo la pista al 
tamaño actual del segmento de datos, que es el valor devuelto por BRK, calculando el nuevo tamaño, y 
realizando una llamada pidiendo ese número de bytes. BRK y SBRK se consideraron demasiado 
dependientes de la implementación y no forman parte de POSIX. 
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' Brecna // 


Dirección (hex) 

FFFF 


Finura 1-11. Los procesos tienen tres segmentos: texto, datos y pila. En este ejemplo, los 
tres están en el mismo espacio de direcciones, pero también se manejan espacios de 
instrucciones y datos separados. 


La siguiente llamada al sistema relacionada con procesos también es la más sencilla, GETPID, que se 
limita a devolver el pid de quien la invoca. Recuerde que en FORK, sólo se proporcionaba el pid del hijo 
al padre. Si el hijo desea conocer su propio pid, deberá usar GETPID. La llamada GETPGRP devuelve el 
pid del grupo de procesos del invocador. SETSID crea una nueva sesión y asigna el pid del invocador al 
pid del grupo de procesos. Las sesiones están relacionadas con una característica opcional de Posix 
llamada control de trabajos, que no es apoyada por MINIX y de la cual no nos ocuparemos más. 

La última llamada al sistema relacionada con procesos, PTRACE, es utilizada por los programas 
depuradores para controlar el programa que se está depurando. Esta llamada permite al depurador leer y 
escribir en la memoria del proceso controlado y administrarla de otras maneras. 


1.4.2 Llamadas al sistema para señalización 

Aunque casi todas las formas de comunicación entre procesos son planeadas, existen situaciones en las 
que se requiere una comunicación inesperada. Por ejemplo, si un usuario accidentalmente le pide a un 
editor de textos que liste todo el contenido de un archivo muy largo, y luego se percata de su error, 
necesita alguna forma de interrumpir el editor. En MINIX, el usuario puede pulsar la tecla DEL (suprimir) 
del teclado, la cual envía una señal al editor. El editor atrapa la señal y detiene el listado. También 
pueden usarse señales para informar de ciertas trampas detectadas por el hardware, como una instrucción 
no permitida o un desbordamiento de punto flotante. Las expiraciones de tiempo también se implementan 
como señales. 

Cuando se envía una señal a un proceso que no ha anunciado su disposición a aceptar esa señal, el 
proceso simplemente se termina sin más. Para evitar esta suerte, un proceso puede usar la llamada 
al sistema SIGACTION para anunciar que está preparada para aceptar algún tipo de señal, y 
proporcionar la dirección del procedimiento que manejará la señal, así como un lugar 
para almacenar la dirección del manejador actual. Después de una llamada a SIGACTION, si se 
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genera una señal del tipo pertinente (p. ej., la tecla DEL), el estado del proceso se mete en su propia pila 
y luego se invoca el manejador de señales, el cual puede ejecutarse durante el tiempo que desee y emitir 
todas las llamadas al sistema que quiera. En la práctica, empero, los manejadores de señales suelen ser 
más o menos cortos. Cuando un procedimiento de manejo de señales termina, llama a SIGRETURN para 
que el proceso continúe donde estaba antes de la señal. La llamada SIGACTION sustituye a la antigua 
llamada SIGNAL, que ahora se proporciona como procedimiento de biblioteca a fin de mantener la 
compatibilidad hacia atrás. 

Las señales pueden bloquearse en MINIX. Una señal bloqueada se mantiene pendiente hasta que se 
desbloquea; no se entrega, pero tampoco se pierde. La llamada SIGPROCMASK permite a un proceso 
definir el conjunto de señales bloqueadas presentando al kemel un mapa de bits. Un proceso también 
puede preguntar por el conjunto de señales que actualmente están pendientes y cuya entrega no se ha 
permitido porque están bloqueadas. La llamada SIGPENDING devuelve este conjunto en forma de mapa 
de bits. Por último, la llamada SIGSUSPEND permite a un proceso establecer atómicamente el mapa de 
bits de las señales bloqueadas y suspenderse a sí mismo. 

En vez de proporcionar una función que atrape una señal, el programa puede especificar la constante 
SIGJGN para que se haga caso omiso de todas las señales subsecuentes del tipo especificado, o 
SIG DFL para restablecer la acción por omisión de la señal cuando ocurra. La acción por omisión es 
terminar el proceso o bien hacer caso omiso de la señal, dependiendo de la señal. Como ejemplo del uso 
de SIG IGN, consideremos lo que sucede cuando el shell bifurca un proceso de segundo plano como 
resultado de 

comando & 

No sería conveniente que una señal DEL del teclado afectara el proceso de segundo plano, así que el shell 
hace lo siguiente después del FORK pero antes del EXEC: 

sigaction(SIGINT, SIG_ING, NULL); 

y 

sigaction(SIGQUIT, SIG ING, NULL); 

para inhabilitar las señales DEL y QUIT. (La señal QUIT se genera con CTRLA; es lo mismo que DEL 
excepto que, si no es atrapada o ignorada, realiza un vaciado de núcleo del proceso que se terminó.) En el 
caso de procesos de primer plano (sin el &), estas señales no se ignoran. 

Pulsar la tecla DEL no es la única forma de enviar una señal. La llamada al sistema KILL permite a un 
proceso enviar una señal a otro proceso (siempre que tengan el mismo uid; los procesos no relacionados 
entre sí no se pueden enviar señales mutuamente). Volviendo al ejemplo del proceso de segundo plano, 
suponga que se inicia un proceso de segundo plano pero posterior- mente se decide que se le debe 
terminar. SIGINT y SIGQUIT han sido inhabilitadas, así que necesitamos algún otro mecanismo. La 
solución es usar el programa kill, que usa la llamada al sistema KII.l. para enviar una señal a cualquier 
proceso. Si enviamos la señal 9 (SIGKILL) a un proceso de segundo plano, podremos terminarlo. 
SIGKILL no puede atraparse ni ignorarse. 

En muchas aplicaciones de tiempo real se hace necesario interrumpir un proceso después de 
un intervalo de tiempo específico a fin de hacer algo, como retrans mi tir un paquete que tal vez se 
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perdió en una línea de comunicación no confiable. Se proporciona la llamada al sistema ALARM para 
manejar esta situación. El parámetro especifica un intervalo, en segundos, después del cual se envía una 
señal SIGALARM al proceso. Un proceso sólo puede tener una alarma pendiente en un momento dado. 
Si se emite una llamada ALARM con un parámetro de 10 segundos, y 3 según- dos después se emite otra 
llamada ALARM con un parámetro de 20 segundos, sólo se generará una señal, 20 segundos después de la 
segunda llamada. La primera señal será cancelada por la segunda llamada ALARM. Si el parámetro de 
ALARM es cero, se cancelará cualquier señal de alarma pendiente. Si una señal de alarma no es atrapada, 
se emprenderá la acción por omisión y se terminará el proceso al que se envió la señal. 

A veces sucede que un proceso no tiene nada que hacer en tanto no llegue una señal. Por ejemplo, 
consideremos un programa de instrucción asistida por computadora que está probando la velocidad de 
lectura y la comprensión. El programa exhibe texto en la pantalla y luego llama a ALARM para que le 
envíe una señal después de 30 segundos. Mientras el estudiante está leyendo el texto, el programa no tiene 
nada que hacer; podría quedar inerte dando vueltas en un ciclo vacío, pero eso desperdiciaría tiempo de 
CPU que otro proceso o usuario podría necesitar. Una solución mejor es usar PAUSE, que le ordena a 
MINIX que suspenda el proceso hasta la siguiente señal. 


1.4.3 Llamadas al sistema para administración de archivos 

Muchas llamadas al sistema se relacionan con el sistema de archivos. En esta sección examinaremos 
llamadas que operan sobre archivos individuales; en la siguiente veremos las que trabajan con 
directorios o el sistema de archivos global. Usamos la llamada CREAT para crear un nuevo archivo (la 
razón por la que esta llamada es CREAT y no CREATE se ha perdido en las brumas del tiempo). Los 
parámetros de CREAT dan el nombre del archivo y el modo de protección. Así, 

Id = creat( “abe “, 0751); 

crea un archivo llamado abe con el modo 0751 octal (en C, un cero inicial indica que una constan- te está 
en octal). Los nueve bits de orden bajo de 0751 especifican los bits rwx para el propietario (7 significa 
permiso de lectura-escritura-ejecución), su grupo (5 significa permiso de lectura- ejecución) y otros (1 
significa sólo ejecución). 

CREAT no sólo crea un archivo nuevo sino que también lo abre para escritura, sea cual sea el modo del 
archivo, Se puede usar el descriptor de archivo devuelto, fd, para escribir el archivo. Si se invoca 
CREAT para un archivo existente, ese archivo se truncará a longitud 0, a condición, desde luego, que los 
permisos sean los correctos. La llamada CREAT es obsoleta, ya que ahora OPEN puede crear archivos 
nuevos, pero se ha incluido para asegurar la compatibilidad hacia atrás. 

Los archivos especiales se crean usando MKNOD en lugar de CREAT. Una llamada típica es 

Id = mknod(”/dev/ttyc2”, 020744, 0x0402); 

que crea un archivo llamado /dev/tlyc2 (el nombre usual para la consola 2) y le asigna el modo 020744 
octal (un archivo especial de caracteres con bits de protección rwxr—r —) El tercer parámetro 
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contiene el dispositivo principal (4) en el byte de orden alto y el dispositivo secundario (2) en el byte de 
orden bajo. El dispositivo principal podría haber sido cualquier cosa, pero un archivo llamado /dev/ttvc2 
debe ser el dispositivo secundario 2. Las llamadas a MKNOD fallarán si el usuario no es el superusuario. 

Para leer o escribir un archivo existente, el archivo primero debe abrirse con OPEN. Esta llamada 
especifica el nombre del archivo que se va a abrir, ya sea como nombre de ruta absoluto o relativo al 
directorio de trabajo, y un código de O RDONL} OWRONLY u ORDWR, que significan abrir para 
lectura, escritura o ambas cosas. El descriptor de archivo devuelto puede usarse entonces para leer o 
escribir. Después, el archivo puede cerrarse con CLOSE, con lo que el descriptor de archivo queda 
disponible para reutilizarse en un CREAT u OPEN subsecuente. 

Las llamadas más utilizadas son sin duda READ y WRITE. Ya vimos READ antes; WRITE (escribir) 
tiene los mismos parámetros. 

Aunque casi todos los programas leen y escriben archivos secuencialmente, algunos programas de 
aplicación necesitan tener acceso directo a cualquier parte de un archivo. Cada archivo tiene asociado un 
apuntador que indica la posición actual en el archivo. Al leer (o escribir) secuencialmente, este apuntador 
normalmente apunta al siguiente byte que se leerá (o escribirá). La llamada LSEEK cambia el valor del 
apuntador de posición, con lo que las llamadas subsecuentes a READ o WRITE pueden comenzar en 
cualquier lugar del archivo, o incluso más allá de su final. 

LSEEK tiene tres parámetros: el primero es el descriptor de archivo para el archivo, el segundo es una 
posición en el archivo y el tercero indica si dicha posición es relativa al principio del archivo, la posición 
actual o el final del archivo. El valor devuelto por LSEEK es la posición absoluta en el archivo una vez 
que se ha cambiado el apuntador. 

Para cada archivo, MINIX se mantiene al tanto del modo del archivo (archivo regular, archivo 
especial, directorio, etc.), su tamaño, la hora de la última modificación y otra información. Los programas 
pueden pedir ver esta información usando las llamadas al sistema STAT y FSTAT. La única diferencia 
entre las dos es que la primera especifica el archivo por su nombre, en tanto que la segunda recibe un 
descriptor de archivo, lo que lo hace útil para archivos abiertos, sobre todo la entrada estándar y la salida 
estándar, cuyos nombres tal vez no se conozcan. Ambas llamadas requieren como segundo parámetro un 
apuntador a una estructura en la cual se colocará la información. La estructura se muestra en la Fig. 1-12. 

Al manipular descriptores de archivo, a veces resulta útil la llamada DUP. Considere, por ejemplo, un 
programa que necesita cerrar la salida estándar (descriptor de archivo 1), sustituir otro archivo como 
salida estándar, invocar una función que escribe ciertas salidas en la salida estándar, y luego restablecer la 
situación original. Basta cerrar el descriptor de archivo 1 y luego abrir un archivo nuevo para hacer que 
ese archivo sea la salida estándar (suponiendo que la entrada estándar, con descriptor de archivo O, esté 
en uso), pero luego será imposible restablecer la situación original. 

La solución consiste en ejecutar primero la instrucción 

fd = dup(l); 

que usa la llamada al sistema DUP para asignar un nuevo descriptor de archivo, fd, y hacer que 
corresponda al mismo archivo que la salida estándar. Luego se puede cerrar la salida estándar y 
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struct stat { 
short st_dev; 
unsigned short stjno; 
unsigned short st_mode; 


r dispositivo donde debe estar ei nodo-i 7 
/* número dei nodo-i 7 
/* palabra de modo 7 
/* número de vínculos 7 
r identificador del usuario 7 
/* identificador del grupo 7 

r dispositivo principal/secundaho para archivos especiales 7 
r tamaño del archivo 7 
r hora del último acceso 7 
/* hora de la última modificación 7 
r hora de la última modificación del nodo-i 7 


short st_nlink; 
short st_uid; 
short st_gid; 
short st_rdev; 
long st.size; 


long st_atime; 


long st_mtime 
long st_ctlme 


}: 


Figura 1-12. La estructura empleada para devolver información para las llamadas al sistema 
STAT y FSTAT. En el código real se usan nombres simbólicos para algunos de los tipos. 


abrir y usar un nuevo archivo. Cuando llegue el momento de restablecer la situación original, se podrá 
cerrar el descriptor de archivo 1 y luego ejecutarse 


n = dup(fd); 


para asignar el descriptor de archivo más bajo, que es 1, al mismo archivo que fd. Por último, puede 
cerrarse fd y estamos otra vez donde empezamos. 

La llamada DUP tiene una variante que permite hacer que un descriptor de archivo arbitrario no 
asignado se refiera a un archivo abierto dado. Esta variante se invoca con 

dup2(fd, fd2); 

donde fd se refiere a un archivo abierto y fd2 es el descriptor de archivo no asignado que ahora se referirá 
al mismo archivo que fd. Por ejemplo, si fd se refiere a la entrada estándar (descriptor de archivo O) y fd2 
es 4, después de la llamada los descriptores de archivo O y 4 se referirán ambos a la entrada estándar. 

La comunicación entre procesos en MINIX emplea conductos, como ya se explicó. Cuando un usuario 
teclea 

cat archivol archivo2 1 sort 

el shell crea un conducto y hace que la salida estándar del primer proceso escriba en el conducto para que 
la entrada estándar del segundo proceso pueda leer de él. La llamada al sistema PIPE crea un conducto y 
devuelve dos descriptores de archivo, uno para escribir y otro para leer. La llamada es 

pipe(&fd[0]); 

donde fd es un arreglo de dos enteros, y fd y fd 11 son los descriptores de archivo para leer y para 
escribir, respectivamente. Por lo regular, después viene un FORK, y el padre cierra el descriptor 
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de archivo para leer y el hijo cierra el descriptor de archivo para escribir (o viceversa), de modo que, 
cuando terminan, uno de los procesos puede leer el conducto y el otro puede escribir en él. 

La Fig. 1-13 muestra un esqueleto de procedimiento que crea dos procesos, enviando la salida del 
primero al segundo por un conducto. (Un ejemplo más realista verificaría errores y manejaría 
argumentos.) Primero se crea un conducto, y luego el procedimiento bifurca. El padre finalmente se 
convierte en el primer proceso de la tubería y el proceso hijo se convierte en el segundo. Puesto que 
los archivos que se van a ejecutar, processl y process2 no saben que forman parte de una tubería, es 
indispensable que los descriptores de archivo se manipulen de modo que la salida estándar del primer 
proceso sea el conducto y la entrada estándar del segundo sea el conducto. El padre cierra primero el 
descriptor de archivo para leer del conducto, luego cierra la salida estándar y emite una llamada DUP 
que permite al descriptor de archivo 1 escribir en el conducto. Es importante tener presente que DUP 
siempre devuelve el descriptor de archivo más bajo disponible, que en este caso es 1. Luego, el programa 
cierra el otro descriptor de archivo del conducto. 

Después de la llamada EXEC, el proceso iniciado tendrá los descriptores de archivo O y 2 sin 
modificación, y el 1 para escribir en el conducto. El código del hijo es análogo. El parámetro para execl se 
repite porque el primero es el archivo que se va a ejecutar y el segundo es el primer parámetro, que casi 
todos los programas esperan que sea el nombre del archivo. 

La siguiente llamada al sistema, IOCTL, es potencialmente aplicable a todos los archivos especiales. 
Por ejemplo, es utilizada por los controladores de dispositivos de bloques como el SCSI para controlar 
dispositivos de cinta y CD-ROM. No obstante, su uso principal es con archivos especiales por caracteres, 
sobre todo las terminales, rosix define varias funciones que la biblioteca traduce a llamadas IOCTL. Las 
funciones de biblioteca tcgetattr y tcsetattr usan IOCTL para cambiar los caracteres que se usan para 
corregir los errores de digitación en la terminal, cambiar el modo de la terminal, etcétera. 

El modo cocido es el modo de ter mi nal normal, en el que los caracteres de borrar y term in ar funcionan 
normalmente, CTRL-S y CTRL-Q pueden usarse para detener e iniciar la salida de la terminal, CTRL-D 
significa fin de archivo, DEL genera una señal de interrupción y CTRLA genera una señal de abandonar 
(quit) para forzar un vaciado de núcleo. 

En modo crudo, todas estas funciones están inhabilitadas; todos los caracteres se pasan directamente al 
programa sin ningún procesamiento especial. Además, en modo crudo una lectura de la ter mi n a l 
proporciona al programa todos los caracteres que se han tecleado, incluso una línea parcial, en lugar de 
esperar hasta que se teclea una línea completa, como en el modo cocido. 

El modo cbreak es intermedio. Los caracteres de borrar y ter mi nar para edición están inhabilitados, lo 
mismo que CTRL-D, pero CTRL-S, CTRL-Q, DEL y CTRLA están habilitados. Al igual que en modo 
crudo, se pueden devolver líneas parciales a los programas (si se desactiva la edición intralíneas no hay 
necesidad de esperar hasta haber recibido una línea completa; el usuario no puede cambiar de opinión y 
eliminarla, como en el modo cocido). 

Posix no utiliza los términos cocido, crudo y cbreak. En la terminología de POS el modo canónico 
corresponde al modo cocido. En este modo están definidos once caracteres especiales, y la entrada es 
por líneas, En el modo no canónico un número mínimo de caracteres por aceptar y un 
tiempo, especificado en unidades de décimas de segundo, determinan la forma en que se satisfará 
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¿define STDJNPUT 0 /* descriptor de archivo para entrada estándar 7 

¿define STD_OUTPUT 1 /* descriptor de archivo para salida estándar 7 

pipeline(processi, process2) 

char *processl, *process2; r apuntadores a nombres de programas 7 

{ 

int fd[2J; 

pipe(&fd[0|); /* crear un conducto 7 

if (fork() != 0) { 

r El proceso padre ejecuta estas instrucciones. 7 

close(fd[0]), r el proceso 1 no necesita leer del conducto 7 

close(STD_OUTPUT); /* preparar la nueva salida estándar 7 

dup<fd(1 J); /* asignar fd[1] a la salida estándar 7 

close(fd[l ]); /* este descriptor de archivo ya no se necesita 7 

execl(processi. processl. 0); 

} else { 

r El proceso hijo ejecuta estas instrucciones. 7 

close(fd[1]); /* el proceso 2 no necesita escribir en el conducto 7 

close(STDJNPUT); /* preparar la nueva entrada estándar 7 

dup(fd[0J); /* asignar td[0] a la entrada estándar 7 

close(fd[0]); f este descriptor de archivo ya no se necesita 7 

execl(process2, process2. 0); 

> 

> 


Figura 1*13. Esqueleto para establecer una tubería de dos procesos. 


una lectura. Bajo POSIX hay un alto grado de flexibilidad, y es posible ajustar diversas banderas para 
hacer que el modo no canónico se comporte como el modo cbreak o el crudo. Los términos antiguos son 
más descriptivos, y seguiremos usándolos informalmente. 

IOCTL tiene tres parámetros; por ejemplo, una llamada a tcsetattr para establecer los parámetros de 
terminal dará lugar a: 

ioctl(fd, TCSETS, &termios); 

El primer parámetro especifica un archivo, el segundo especifica una operación y el tercero es la 
dirección de la estructura iosix que contiene banderas y el arreglo de caracteres de control. Otros 
códigos de operación pueden posponer los cambios hasta que se haya enviado toda la salida, hacer que 
las entradas no leídas se desechen, y devolver los valores actuales. 

La llamada al sistema ACCESS sirve para determinar si el sistema de protección permite cierto 
acceso a un archivo. Esta llamada es necesaria porque algunos programas pueden ejecutarse usando el 
uid de un usuario distinto. Este mecanismo de SETUID se describirá posteriormente. 
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La llamada al sistema RENAME sirve para dar a un archivo un nuevo nombre. Los parámetros 
especifican los nombres viejo y nuevo. 

Por último, la llamada FCNTL se usa para controlar archivos de forma un tanto análoga a IOCTL (es 
decir, ambas son hacks horribles). Esta llamada tiene varias opciones, la más importante de las cuales es 
para poner candados a archivos a discreción. Usando FCNTL, un proceso puede poner y quitar candados a 
partes de archivos y probar una parte de un archivo para ver si tiene candado. La llamada no impone 
ninguna semántica de candados; los programas deben encargarse de ello. 


1.4.4 Llamadas al sistema para administración de directorios 

En esta sección exa mi naremos algunas llamadas al sistema que más bien están relacionadas con 
directorios o con el sistema de archivos global, no con un archivo específico como en la sección anterior. 
Las dos primeras llamadas, MKDIR y RMDIR, crean y eliminan directorios vacíos, respectivamente. La 
siguiente llamada es LINK. Su propósito es hacer posible que el mismo archivo aparezca con dos o más 
nombres, a menudo en diferentes directorios. Un uso típico es permitir que varios miembros del mismo 
equipo de programación compartan un archivo común, y que para cada uno el archivo aparezca en su 
propio directorio, tal vez con un nombre distinto. Compartir un archivo no es lo mismo que dar a cada 
miembro del equipo una copia privada, porque al tener un archivo compartido los cambios que cualquier 
miembro del equipo efectúan son visibles de in- mediato para los otros miembros: sólo existe un archivo. 
Cuando se hacen copias de un archivo, los cambios subsecuentes que se hagan a una copia no afectarán a 
las demás. 

Para ver cómo funciona LINK, consideremos la situación de la Fig. l-14(a). Aquí hay dos usuarios, 
ast y jim, cada uno de los cuales tiene sus propios directorios con varios archivos. Si ahora ast ejecuta un 
programa que contiene la llamada al sistema 

link( “usr/jim/memo”, “/usr/ast/note 

el archivo memo del directorio de jim se incluye ahora en el directorio de ast con el nombre note. En 
adelante, /usr/jim/memo y /usr/ast/note se referirán al mismo archivo. 


/usr/ast /usr/jim 


16 

mail 


31 

bin 

81 

gamos 


70 

memo 

40 

test 


59 

f.c 
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16 

mail 


31 

bin 

81 

gamos 


70 

memo 

40 

test 


59 

f.c. 

70 

note 


38 

progl 


(b) 


Figura 1-14. (a) Dos directorios antes de vincular / usr/jim/memo al directorio de asi. 
(b) Los mismos directorios después de la vinculación. 


Si entendemos cómo fúnciona LINK tal vez nos quedará más claro qué resultado produce. Todos 
los archivos en MINIX tienen un número único, su número-i, que lo identifica. Este número-i 
es un índice de una tabla de nodos-i, uno por archivo, que indican quién es el dueño del 
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archivo, dónde están sus bloques de disco, etc. Un directorio no es más que un archivo que contiene un 
conjunto de pares (número-i, nombre ASCII). En la Fig. 1-14, mail tiene el número-i 16, por ejemplo. Lo 
que LINK hace es simplemente crear una nueva entrada de directorio con un nombre (posiblemente 
nuevo) usando el número-i de un archivo existente. En la Fig. l-14(b), dos entradas tienen el mismo 
número-i (70) y por tanto se refieren al mismo archivo. Si cualquiera de estas entradas se eli mi na 
posteriormente, usando la llamada al sistema UNLINK, la otra permanecerá. Si ambas se eliminan, 
MINIX verá que no existen entradas para el archivo (un campo del nodo-i indica cuántas entradas de 
directorio apuntan al archivo), y entonces lo eli mi nará del disco. 

Como dijimos antes, la llamada al sistema MOUNT permite fúsionar dos sistemas de archivos para 
formar uno solo. Una situación común es tener el sistema de archivos raíz, que contiene las versiones 
binarias (ejecutables) de los comandos comunes y otros archivos de uso intensivo, en el disco en RAM. El 
usuario podría después, por ejemplo, insertar en la unidad O un disco flexible con programas de usuario. 

Si se ejecuta la llamada al sistema MOUNT, el sistema de archivos de la unidad O se puede conectar 
al sistema de archivos raíz, como se muestra en la Fig. 1-15. Una instrucción típica en C para realizar el 
montaje es 

mount(“/dev/fdO”, “/mnt”, 0); 

donde el primer parámetro es el nombre de un archivo especial por bloques para la unidad O y el segundo 
parámetro es el lugar del árbol donde se debe montar. 




(a) 


Figura 1*15. Sistema de archivos (a) antes del montaje y (b) después del montaje. 


Después de la llamada MOUNT, se puede acceder a un archivo en la unidad O usando su ruta desde el 
directorio raíz o desde el directorio de trabajo, sin importar en qué unidad esté. De hecho, se pueden 
montar una segunda, tercera y cuarta unidad en cualquier lugar del árbol. El comando MOUNT permite 
integrar medios removibles en una sola jerarquía de archivos integrada sin tener que preocuparse respecto 
a cuál es el dispositivo en el que está un archivo. Aunque en este ejemplo se habló de discos flexibles, 
también pueden montarse de este modo discos duros o porciones de discos duros (también llamados 
particiones o dispositivos secundarios). Si un sistema de archivos ya no se necesita, puede desmontarse 
con la llamada al sistema UNMOUNT. 

MINIX mantiene un caché en la memoria principal con los bloques usados más recientemente 
a fin de no tener que leerlos del disco si se vuelven a usar en un lapso corto. Si se modifica un 
bloque del caché (por un WRITE a un archivo) y el sistema se cae antes de que el bloque modificado 
se grabe en el disco, el sistema de archivos se dañará. Para li mi tar el daño potencial, es importante 
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desalojar el caché periódicamente, de modo que la cantidad de datos que se pierdan en caso de una caída 
sea pequeño. La llamada al sistema SYNC le dice a MINIX que escriba en disco todos los bloques del 
caché que hayan sido modificados después de haberse leído. Cuando se inicia MINIX, se pone en marcha 
un programa llamado update (actualizar) que se ejecuta en segundo plano, invocando SYNC cada 30 
segundos a fin de desalojar continuamente el caché. 

Otras dos llamadas relacionadas con directorios son CHDIR y CHROOT. La primera cambia el 
directorio de trabajo y la segunda cambia el directorio raíz. Después de la llamada 

chdir( “/usr/astltest”); 

un OPEN ejecutado con el archivo xyz abrirá /usr/ast/test/xyz. CHROOT funciona de forma análoga. Una 
vez que un proceso le ha ordenado al sistema que cambie su directorio raíz, todos los nombres de ruta 
absolutos (los que comienzan con “1”) partirán de la nueva raíz. Sólo los superusuarios pueden ejecutar 
CHROOT, e incluso ellos no lo hacen con mucha frecuencia. 


1.4.5 Llamadas al sistema para protección 


En MINIX todos los archivos tienen un modo de 11 bits que se utiliza para protección. Nueve de estos bits 
son los de leer-escribir-ejecutar para el propietario, el grupo y otros. La llamada al sistema CHMOD hace 
posible cambiar el modo de un archivo. Por ejemplo, para hacer que un archivo sea sólo de lectura para 
todos excepto su propietario, podemos ejecutar 

chmod( “archivo “, 0644); 

Los otros dos bits de protección, 02000 y 04000, son los bits SETGID (establecer identificador de 
grupo) y SETUID (establecer identificador de usuario), respectivamente. Cuando cualquier usuario ejecuta 
un programa que tiene activado el bit SETUID, el uid efectivo de ese usuario se cambia al del propietario 
del archivo durante la ejecución del proceso. Esta capacidad se utiliza mucho para permitir a los usuarios 
ejecutar programas que realizan funciones exclusivas del superusuario, como crear directorios. Para crear 
un directorio se usa MKNOD, que es sólo para el superusuario. Si se hace que el propietario del programa 
mkdir sea el superusuario y que ese programa tenga el modo 04755, se podrá otorgar a los usuarios la 
facultad de ejecutar MKNOD pero en una forma muy restringida. 

Cuando un proceso ejecuta un archivo que tiene el bit SETUID o SETGID activado en su modo, 
adquiere un uid o gid efectivo diferente de su uid o gid real. A veces es importante para un proceso 
averiguar cuáles son su uid o gid real y efectivo. Las llamadas al sistema GETUID y GETGID se 
incluyeron para proporcionar esa información. Cada llamada devuelve el uidlgid tanto real como efectivo, 
así que se necesitan cuatro rutinas de biblioteca para extraer la información apropiada: getuid, getgid, 
geteuid y getegid. Las primeras dos obtienen el uidlgid real, y las dos últimas, el uid/gid efectivo. 

Los usuarios ordinarios no pueden cambiar su uid, excepto ejecutando programas con el bit SETUID 
activado, pero el superusuario tiene otra posibilidad: la llamada al sistema SETUID, que establece los uid 
tanto efectivo como real. SETGID establece ambos gid. El superusuario también puede cambiar el 
propietario de un archivo mediante la llamada al sistema CHOWN. En pocas 
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palabras, el superusuario tiene abundantes oportunidades para violar todas las reglas de protección, lo que 
explica por qué tantos estudiantes dedican tanto de su tiempo a tratar de convertirse en superusuarios. 

Las últimas dos llamadas al sistema de esta categoría pueden ser ejecutadas por procesos de usuario 
ordinarios. La primera, UMASK, establece una máscara de bits interna dentro del sistema, la cual se usará 
para enmascarar los bits del modo cuando se cree un archivo. Después de la llamada 

umask(022); 

el modo proporcionado por CREAT y MKNOD tendrá los bits 022 enmascarados antes de usarse. Así, la 
llamada 

creat( “archivo “, 0777); 

asignará 0755 al modo en lugar de 0777. Puesto que la máscara de bits es heredada por los procesos hijo, 
si el shell ejecuta un UMASK justo después del inicio de sesión, ninguno de los procesos de usuario de 
esa sesión creará accidentalmente archivos en los que otras personas puedan escribir. 

Cuando un programa propiedad de la raíz tiene el bit SETUID activado, puede acceder a cualquier 
archivo, pues su uid efectivo es el del superusuario. En muchos casos al programa le resulta útil saber si la 
persona que lo invocó tiene permiso para acceder a un archivo dado. Si el programa simplemente intenta 
acceder a él, siempre lo logrará, y no habrá averiguado nada. 

Lo que se necesita es una forma de saber si el acceso está permitido para el uid real. La llamada al 
sistema ACCESS ofrece una forma de averiguarlo. El parámetro mode es 4 para verificar si hay acceso de 
lectura, 2 para acceso de escritura y 1 para acceso de ejecución. También se permiten combinaciones; por 
ejemplo, si mode es 6, la llamada devolverá 0 si el uid real tiene permiso tanto de escritura como de 
escritura; en caso contrario, devolverá —1. Si mode es 0, se verifica si existe el archivo y si se pueden 
efectuar búsquedas en los directorios que conducen a él. 


1.4.6 Llamadas al sistema para administración del tiempo 

MINIX tiene cuatro llamadas al sistema relacionadas con el reloj de hora del día. TIME simplemente 
devuelve el tiempo actual en segundos, donde O corresponde al lo. de enero de 1970 a la media noche 
(justo en el momento de comenzar el día, no al terminar). Desde luego, el reloj del sistema debe 
establecerse en algún momento para poder leerlo después, y es para ello que se ha incluido la llamada 
STIME que permite al superusuario establecer el reloj. La tercera llamada relacionada con el tiempo es 
UTIME, que permite al propietario de un archivo (o al superusuario) alterar el tiempo almacenado en el 
nodo-i de un archivo. La aplicación de esta llamada es muy limitada, pero unos cuantos programas la 
necesitan; por ejemplo, touch, que asigna el tiempo actual al tiempo del archivo. 

Por último, tenemos TIMES, que devuelve la información de contabilidad a un proceso, a fin de que 
pueda saber Cuánto tiempo de CPU usó directamente y cúanto tiempo de CPU gastó el sistema a su 
nombre (manejando sus llamadas al sistema). También se devuelven los tiempos de usuario y de sistema 
totales gastados por todos los hijos de ese proceso combinados. 
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1.5 ESTRUCTURA DEL SISTEMA OPERATIVO 

Ahora que hemos visto qué aspecto tienen los sistemas operativos por fuera (es decir, la interfaz con el 
programador), ha llegado el momento de dar una mirada al interior. En las siguientes secciones 
examinaremos cuatro estructuras distintas que se han probado, a fin de tener una idea de la variedad de 
posibilidades. Éstas no son de ninguna manera las únicas estructuras posibles, pero nos darán una idea de 
algunos diseños que se han llevado a la práctica. Los cuatro diseños son los sistemas monolíticos, los 
sistemas por capas, las máquinas virtuales y los sistemas cliente-servidor. 


1.5.1 Sistemas monolíticos 

Este enfoque, que es por mucho la organización más común, bien podría subtitularse “El Gran Desorden”. 
La estructura consiste en que no hay estructura. El sistema operativo se escribe como una colección de 
procedimientos, cada uno de los cuales puede invocar a cualquiera de los otros cuando necesita hacerlo. 
Cuando se usa esta técnica, cada procedimiento del sistema tiene una interfaz bien definida en tér mi nos de 
parámetros y resultados, y cada uno está en libertad de invocar a cualquier otro, si este último realiza 
algún cálculo útil que el primero necesita. 

Para construir el programa objeto real del sistema operativo cuando se adopta este enfoque, lo 
primero que se hace es compilar todos los procedimientos individuales, o archivos que contienen los 
procedimientos, y luego se vinculan en un solo archivo objeto usando el vinculador (linker) del sistema. 
En términos de ocultación de la información, prácticamente no hay tal; todos los procedimientos son 
visibles para todos los demás (en contraposición a una estructura que contiene módulos o paquetes, en la 
que gran parte de la información se oculta dentro de los módulos, y sólo se pueden invocar desde fúera del 
módulo los puntos de entrada designados oficialmente). 

No obstante, incluso en los sistemas monolíticos es posible tener al menos un poco de estructura. Los 
servicios (llamadas al sistema) proporcionados por el sistema operativo se solicitan colocando los 
parámetros en lugares bien definidos, como en registros o en la pila, y ejecutando después una instrucción 
de trampa especial conocida como llamada al kernel o llamada al supervisor. 

Esta ins trucción conmuta la máquina del modo de usuario al modo de kernel y transfiere el control al 
sistema operativo, lo cual se muestra como evento (1) en la Fig. 1-16. (La mayor parte de las CPU tienen 
dos modos: modo de kernel, para el sistema operativo, en el que se permite todas las instrucciones; y 
modo de usuario, para programas de usuario, en el que no se permiten instrucciones de E/S y de ciertos 
otros tipos.) 

A continuación, el sistema operativo examina los parámetros de la llamada para determinar cuál 
llamada al sistema se ejecutará; esto se muestra como (2) en la Fig. 1-16. Acto seguido, el 
sistema operativo consulta una tabla que contiene en la ranura k un apuntador al procedimiento que 
lleva a cabo la llamada al sistema k. Esta operación, marcada con (3) en la Fig. 1-16, 
identifica el procedimiento de servicio, mismo que entonces se invoca. Una vez que se ha completado 
el trabajo y la llamada al sistema ha terminado, se devuelve el control al programa de 
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Figura 1-16. Cómo puede realizarse una llamada ai sistema: (1) El programa de usuario 
entra en el kemel por una trampa. (2) El sistema operativo determina el número de servicio 
requerido. (3) El sistema operativo invocad procedimiento de servicio. (4) Se devuelve el 
control al programa de usuario. 


usuario (paso 4) a fin de que pueda continuar su ejecución con la instrucción que sigue a la llamada al 
sistema. 

Esta organización sugiere una estructura básica para el sistema operativo: 

1. Un programa principal que invoca el procedimiento de servicio solicitado. 

2. Un conjunto de procedimientos de servicio que llevan a cabo las llamadas al sistema. 

3. Un conjunto de procedimientos de utilería que ayudan a los procedimientos de servicio. 

En este modelo, para cada llamada al sistema hay un procedimiento de servicio que se ocupa de ella. Los 
procedimientos de utilería hacen cosas que varios procedimientos de servicio necesitan, como obtener 
datos de los programas de usuario. Esta división de los procedimientos en tres capas se muestra en la Fig. 
1-17. 



Figura 1-17. Modelo de estructuración sencillo para un sistema monolítico. 
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1.5.2 Sistemas por capas 

Una generalización del enfoque de la Fig. 1-17 consiste en organizar el sistema operativo como una 
jerarquía de capas, cada una construida sobre la que está abajo de ella. El primer sistema que tuvo esta 
estructura fue el sistema THE construido en la Technische Hogeschool Eindhoven de los Países Bajos por 
E. W. Dijkstra (1968) y sus estudiantes. El sistema THE era un sencillo sistema por lotes para una 
computadora holandesa, la Electrologica X8, que tenía 32K de palabras de 27 bits (los bits eran costosos 
en esos tiempos). 

El sistema tenía sE/S capas, como se muestra en la Fig. 1-18. La capa Ose ocupaba del reparto del 
procesador, conmutando entre procesos cuando ocurrían interrupciones o expiraban temporizadores. Más 
arriba de la capa O, el sistema consistía en procesos secuenciales, cada uno de los cuales podía 
programarse sin tener que preocuparse por el hecho de que múltiples procesos se estuvieran ejecutando en 
un solo procesador. En otras palabras, la capa O se encargaba de la multiprogramación básica de la CPU. 


Capa 

Función 

5 

El operador 

4 

Programas de usuario 

IjT 

Administración de entrada/salida 

2 

Comunicación operador-proceso 

1 

Administración de memoria y tambor 

0 

Reparto del procesador y multiprogramación 


Figura 1-18. Estructura del sistema operativo THE. 


La capa 1 administraba la memoria, repartiendo espacio para los procesos en la memoria principal y 
en un tambor de 512K palabras que servía para contener partes de los procesos (páginas) para las que no 
había espacio en la memoria principal. Más arriba de la capa 1, los procesos no tenían que preocuparse 
por si estaban en la memoria o en el tambor; el software de esa capa se encargaba de que se colocaran en 
la memoria las páginas en el momento en que se necesitaban. 

La capa 2 manejaba la comunicación entre cada proceso y la consola del operador. Por encima de 
esta capa cada proceso tenía efectivamente su propia consola de operador. La capa 3 se encargaba de 
administrar los dispositivos de E/S y de colocar en buffers las corrientes de información provenientes de y 
dirigidas a ellos. Más arriba de la capa 3 cada proceso podía tratar con dispositivos de E/S abstractos con 
propiedades bonitas, en lugar de dispositivos reales con muchas peculiaridades. En la capa 4 se 
encontraban los programas de usuario, los cuales no tenían que preocuparse por la administración de 
procesos, memoria, consola o E/S. El proceso del operador del sistema estaba en la capa 5. 

Una forma más generalizada del concepto de capas estuvo presente en el sistema MULTICS. 
En vez de estar organizado en capas, MULTICS estaba organizado como una serie de anillos 
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concéntricos, siendo los interiores más privilegiados que los exteriores. Cuando un procedimiento de un 
anillo exterior quería invocar a uno de un anillo interior, tenía que emitir el equivalente de una llamada al 
sistema, es decir, ejecutar una instrucción TRAP cuyos parámetros se examinaban cuidadosamente para 
comprobar su validez antes de permitir que la llamada procediera. Aunque todo el sistema operativo 
formaba parte del espacio de direcciones de cada proceso de usuario en MULTICS, el hardware permitía 
designar procedimientos individuales (en realidad, segmentos de memoria) como protegidos contra 
lectura, escritura o ejecución. 

En tanto el esquema por capas del sistema THE era en realidad sólo una ayuda para el diseño, ya que 
todas las partes del programa en última instancia se vinculaban en un solo programa objeto, en MULTICS 
el mecanismo de anillo estaba muy presente en el momento de la ejecución y el hardware obligaba a 
ajustarse a él. La ventaja del mecanismo de anillo es que fácilmente puede extenderse para estructurar los 
subsistemas de usuario. Por ejemplo, un profesor podría escribir un programa para probar y calificar los 
programas de los estudiantes y ejecutar este programa en el anillo n, con los programas de los 
estudiantes ejecutándose en el anillo n + 1 para que los estudiantes no puedan modificar sus calificaciones. 


1.5.3 Máquinas virtuales 

Las primeras versiones de OS/360 eran sistemas estrictamente por lotes. No obstante, muchos usuarios de 
360 querían tener tiempo compartido, de modo que diversos grupos, tanto dentro como fuera de IBM, 
decidieron escribir sistemas de tiempo compartido para él. El sistema de tiempo compartido oficial de 
IBM, TSS/360, se entregó tarde, y cuando por fin llegó era tan grande y lento que pocos sitios realizaron 
la conversión. Linalmente, este sistema fue abandonado después de que su desarrollo había consumido 
unos 50 millones de dólares (Graham, 1970). Por otro lado, un grupo del Centro Científico de IBM en 
Cambridge, Massachusetts, produjo un sistema radical- mente diferente que IBM finalmente aceptó como 
producto, y que ahora se utiliza ampliamente en las macrocomputadoras IBM que quedan. 

Este Sistema, llamado originalmente CP/CMS y que más adelante fue rebautizado como VM/ 370 
(Seawright y MacKinnon, 1979), se basaba en una astuta observación: un sistema de tiempo compartido 
ofrece (1) multiprogramación y (2) una máquina extendida con una interfaz más cómoda que el hardware 
solo. La esencia de VM!370 consiste en separar por completo estas dos funciones. 

El corazón del sistema, conocido como monitor de máquina virtual, se ejecuta en el hardware solo y 
realiza la multiprogramación, proporcionando no una, sino varias máquinas virtuales a la siguiente capa 
superior, como se muestra en la Fig. 1-19. Sin embargo, a diferencia de otros sistemas operativos, estas 
máquinas virtuales no son máquinas extendidas, con archivos y otras características bonitas; más bien, son 
copias exactas del hardware solo, incluido el modo de kemel/usuario, E/S, interrupciones y todo lo demás 
que la máquina real tiene. 

Puesto que cada máquina virtual es idéntica al verdadero hardware, cada una puede ejecutar cualquier 
sistema operativo que se ejecutaría directamente en el hardware solo. Diferentes máquinas 
virtuales pueden, y con frecuencia lo hacen, ejecutar diferentes sistemas operativos. 
Algunos ejecutan uno de los descendientes de OS/360 para procesamiento por lotes o de transacciones, 
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Instrucciones de E/S aquí 
Trampa aquí - 


Máquinas 370 virtuales 


: 3 - 




Hardware solo de 370 


Llamadas al sistema aquí 
Trampa aquí 


Figura 1-19. La estructura de VM/J70 con CMS. 


mientras que otros ejecutan un sistema interactivo monousuario llamado CMS (Sistema de Monitoreo de 
Conversaciones) para usuarios de tiempo compartido. 

Cuando un programa de usuario ejecuta una llamada al sistema, la llamada se atrapa y se envía al 
sistema operativo de su propia máquina virtual, no al VM/370, tal como se haría si el programa se 
estuviera ejecutando en una máquina real en lugar de una virtual. A continuación, CMS emite las 
instrucciones de E/S del hardware normal para leer su disco virtual, o lo que sea que se necesite para 
llevar a cabo la llamada. Estas instrucciones de E/S son atrapadas por el VM/370, el cual, entonces, las 
ejecuta como parte de su simulación del hardware real. Al separar por completo las funciones de 
multiprogramación y de suministro de una máquina extendida, cada uno de los componentes puede ser 
mucho más sencillo, flexible y fácil de mantener. 

El concepto de máquina virtual se usa mucho hoy día en un contexto diferente: la ejecución de 
viejos programas para MS-DOS en una Pentium (u otra CPU Intel de 32 bits). Al diseñar la Pentium y su 
software, tanto Intel como Microsoft se dieron cuenta de que habría una gran de- manda por ejecutar 
software viejo en el nuevo hardware. Por esta razón, Intel proveyó un modo 8086 virtual en la Pentium. 
En este modo, la máquina actúa como una 8086 (que es idéntica a una 8088 desde la perspectiva del 
software) incluido direccionamiento de 16 bits con un límite de 1 MB. 

Este modo es utilizado por WINDOWS, OS2 y otros sistemas operativos para ejecutar programas de 
MS-DOS. Estos programas se inician en modo 8086 virtual y, en tanto ejecuten instrucciones normales, 
operan en el hardware solo. Sin embargo, cuando un programa trata de entrar por una trampa al sistema 
operativo para efectuar una llamada al sistema, o trata de realizar E/S protegida directamente, ocurre una 
trampa al monitor de la máquina virtual. 

Hay dos posibles variantes de este diseño. En la primera, se carga el MS-DOS mismo en el espacio de 
direcciones de la 8086 virtual, de modo que el monitor de la máquina virtual simple- mente refleja la 
trampa de vuelta a MS-DOS, tal como ocurriría en una 8086 real. Después, cuando MS-DOS trata de 
efectuar la E/S él mismo, esa operación es atrapada y llevada a cabo por el monitor de la máquina virtual. 

En la otra variante, el monitor de la máquina virtual simplemente atrapa la primera trampa y efectúa 
la E/S él mismo, ya que conoce todas las llamadas al sistema de MS-DOS y, por tanto, sabe 
lo que se supone que debe hacer cada trampa. Esta variante es menos pura que la primera, 
ya que sólo emula MS-DOS correctamente, y no otros sistemas operativos, como hace la primera. Por 
otro lado, esta variante es mucho más rápida, ya que no tiene que iniciar MS-DOS para llevar a cabo la 
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E/S. Una desventaja adicional de ejecutar realmente MS-DOS en modo 8086 virtual es que MS-DOS 
se mete mucho con el bit que habilita/inhabilita las interrupciones, y la emulación de esto resulta 
muy costosa. 

Vale la pena señalar que ninguno de estos enfoques es realmente idéntico al de VM/370, ya que 
la máquina que está siendo emulada no es una Pentium completa, sino sólo una 8086. En el 
sistema VM/370 es posible ejecutar el VM/370 mismo en la máquina virtual. Con la Pentium, no es 
posible ejecutar, digamos, WINDOWS en la 8086 virtual porque ninguna versión de WINDOWS se 
ejecuta en una 8086; 286 es lo mínimo incluso para la versión más antigua, y no se proporciona 
emulación de 286 (y mucho menos de Pentium). 

Con VM/T7o, cada proceso de usuario obtiene una copia exacta de la computadora real; con el 
modo 8086 virtual en la Pentium, cada proceso usuario obtiene una copia exacta de una computadora 
distinta. Yendo un paso más allá, investigadores en el M.I.T. han construido un sistema que proporciona a 
cada usuario un clon de la computadora real, pero con un subconjunto de los recursos (Engler et al., 1995). 
Así, una máquina virtual podría obtener los bloques de disco O a 1023, el siguiente podría obtener los 
bloques 1024 a 2047, etcétera. 

En la capa más baja, ejecutándose en modo de kemel, hay un programa llamado exokernel, 
cuyo trabajo consiste en repartir recursos a las máquinas virtuales y luego verificar los intentos 
por usarlos para asegurarse de que ninguna máquina esté tratando de usar los recursos de alguien 
más. Cada máquina virtual en el nivel de usuario puede ejecutar su propio sistema operativo, 
como en VM/370 y el modo 8086 virtual de la Pentium, excepto que cada uno sólo puede usar los 
recursos que ha solicitado y que le han sido asignados. 

La ventaja del esquema de exokernel es que ahorra una capa de mapeo. En otros diseños, 
cada máquina virtual cree que tiene su propio disco, cuyos bloques van desde O hasta algún 
máximo, de modo que el monitor de máquina virtual debe mantener tablas para establecer la 
correspondencia con las direcciones de disco reales (y todos los demás recursos). Con el exokernel, 
no es necesario realizar este segundo mapeo. Lo único que el exokernel tiene que hacer es 
mantenerse al tanto de qué recursos se han asignado a cada máquina virtual. Este método sigue 
teniendo la ventaja de separar la multiprogramación (en el exokernel) y el código de sistema 
operativo del usuario (en el espacio del usuario), pero el gasto extra es menor, ya que todo lo que 
el exokernel tiene que hacer es evitar que las máquinas virtuales tomen cosas que no les pertenecen. 


1.5.4 Modelo cliente-servidor 


VM1370 se simplifica mucho al desplazar una parte importante del código de sistema operativo 
tradicional (que implementa la máquina extendida) a una capa superior, CMS. No obstante, el 
VM/370 en sí sigue siendo un programa complejo porque simular varias 370 virtuales no es tan 
fácil (sobre todo si se desea hacerlo con una eficiencia razonable). 

Una tendencia en los sistemas operativos modernos es llevar aún más lejos esta idea de 
trasladar código a capas superiores y quitarle lo más que se pueda al sistema operativo, dejando 
un kemel mínimo. El enfoque usual consiste en implementar la mayor parte de las funciones del 
sistema operativo en procesos de usuario. Para solicitar un servicio, como leer un bloque de un 
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archivo, un proceso de usuario (ahora llamado proceso cliente) envía la solicitud a un proceso servidor, 
el cual realiza el trabajo y devuelve la respuesta. 


Proceso 

cliente 

Proceso 

cliente 

Servidor de 
procesos 

Servidor de 
terminales 

... 

Servidor de 
archivos 

Servidor de 
memoria 




Kernel \ 


Modo de usuario 


Modo de kerr>el 


v El cliente obtiene servicio 
enviando mensajes a 
procesos del servidor 


Figura 1-20. El modelo cliente-servidor. 


En este modelo, que se muestra en la Fig. 1-20, lo único que el kemel hace es manejar la 
comunicación entre los clientes y los servidores. Al dividir el sistema operativo en partes, cada 
una de las cuales sólo se encarga de una faceta del sistema, como el servicio de archivos, de procesos, de 
ter mi n a les o de memoria, cada parte puede ser pequeña y manejable. Además, dado 
que todos los servidores se ejecutan como procesos en modo de usuario, y no en modo de kemel, 
no tienen acceso directo al hardware. Por tanto, si se activa un error en el servidor de archivos, es 
posible que el servicio de archivos se caiga, pero normalmente esto no hará que se caiga toda la 
máquina. 

Otra ventaja del modelo cliente-servidor es su adaptabilidad para usarse en sistemas distribuidos 
(véase la Fig. 1-2 1). Si un cliente se comunica con un servidor enviándole mensajes, el cliente no 

necesita saber si el mensaje será atendido localmente en su propia máquina o si se envió a 
través de la red a un servidor en una máquina remota. En lo que al cliente concierne, sucede lo 
mismo en ambos casos: se envía una solicitud y se obtiene una respuesta. 


Máquina 1 Máquina 2 Máquina 3 Máquina 4 



Mensaje de un cliente 
a un servidor 


Figura 1*21. El modelo cliente-servidor en un sistema distribuido. 


La imagen que acabamos de presentar de un kemel que sólo se encarga del transporte de 
mensajes de los clientes a los servidores y de regreso no es del todo realista. Algunas funciones 
del sistema operativo (como cargar comandos en los registros de los dispositivos de E/S físicos) 
son difíciles, si no imposibles, de efectuar desde programas del espacio de usuarios. Hay dos 
formas de resolver este problema. Una consiste en hacer que algunos procesos de servidor críticos 
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(p. ej., los controladores de dispositivos de E/S) se ejecuten realmente en modo de kemel, con 
acceso completo a todo el hardware, pero que se comuniquen con los demás procesos empleando 
el mecanismo de mensajes normal. 

La otra solución consiste en incorporar una cantidad mínima de mecanismo en el kemel pero 
dejar las decisiones de política a los servidores en el espacio de usuarios. Por ejemplo, el kemel 
podría darse cuenta de que un mensaje enviado a cierta dirección especial implica que debe 
tomarse el contenido de ese mensaje y cargarlo en los registros de dispositivo de E/S de algún 
disco, a fin de iniciar una lectura de disco. En este ejemplo, el kemel ni siquiera inspeccionaría 
los bytes del mensaje para verificar si son válidos o significativos; sólo los copiaría ciegamente 
en los registros del dispositivo de disco. (Obviamente, debe utilizarse algún esquema para limitar 
tales mensajes sólo a los procesos autorizados.) La división entre mecanismo y política es un 
concepto importante; aparece una y otra vez en los sistemas operativos en diferentes contextos. 


1.6 BOSQUEJO DEL RESTO DEL LIBRO 


Los sistemas operativos por lo regular tienen cuatro componentes principales: administración de 
procesos, administración de dispositivos de E/S, administración de memoria y administración 
de archivos. MINIX también está dividido en estas cuatro partes. Los siguientes cuatro capítulos se 
ocupan de estos cuatro temas, uno por capítulo. El capítulo 6 es una lista de lecturas sugeridas y 
una bibliografía. 

Los capítulos sobre procesos, E/S, administración de memoria y sistemas de archivos tienen 
la misma estructura general. Primero se presentan los principios generales del tema. Luego viene 
una reseña del área correspondiente de MINIX (que también aplica a UNIX). Por último, se analiza 
con detalle la implementación en MINIX. Los lectores a los que sólo les interesan los principios 
generales de los sistemas operativos y no el código de MINIX pueden pasar por alto o sólo hojear 
la sección de implementación sin pérdida de continuidad. Los lectores a los que sí les interesa 
averiguar cómo fúnciona un sistema operativo real (MINIX) deberán leer todas las secciones. 


1.7 RESUMEN 


Los sistemas operativos pueden verse desde dos perspectivas: administradores de recursos y má¬ 
quinas extendidas. Desde la perspectiva de administrador de recursos, la tarea del sistema operativo 
es administrar con eficiencia las diferentes partes del sistema. Desde la perspectiva de máquina 
extendida, la tarea del sistema operativo es proporcionar a los usuarios una máquina virtual que 
sea más cómoda de usar que la máquina real. 

Los sistemas operativos tienen una historia larga, que se remonta a los días en que sustituían 
al operador y llega hasta los sistemas de multiprogramación actuales. 

El corazón de cualquier sistema operativo es el conjunto de llamadas al sistema que puede 
manejar. Éstas nos dicen qué es lo que realmente hace el sistema operativo. En el caso de MINIX, 
las llamadas al sistema se pueden dividir en sE/S grupos. El primer grupo tiene que ver con 
la 
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creación y terminación de procesos. El segundo grupo maneja las señales. El tercer grupo sirve 
para leer y escribir archivos. Un cuarto grupo se encarga de la administración de directorios. El 
quinto grupo protege la información, y el sexto grupo se ocupa de llevar el tiempo. 

Los sistemas operativos se pueden estructurar de diversas maneras. Las más comunes son 
como sistema monolítico, como una jerarquía de capas, como sistema de máquina virtual y usan¬ 
do el modelo cliente-servidor. 


PROBLEMAS 


1. Señale las dos funciones principales de un sistema operativo. 

2. ¿Qué es la multiprogramación? 

3. ¿Qué es el spooling ¿Cree usted que las computadoras personales avanzadas contarán con spooling 
como capacidad estándar en el futuro? 

4. En las primeras computadoras, cada byte de datos leído o escrito era manejado directamente por la CPU 
(es decir, no había DMA: acceso directo a memoria). ¿Qué implicaciones tiene esta organización para la 
multiprogramación? 

5. ¿Por qué no era muy común el tiempo compartido en las computadoras de la segunda generación? 

6. ¿Cuáles de las siguientes instrucciones sólo deben permitirse en modo de kemel? 

(a) Inhabilitar todas las interrupciones. 

(b) Leer el reloj de hora del día. 

(c) Establecer el reloj de hora del día. 

(d) Cambiar el mapa de memoria. 

7. Cite algunas diferencias entre los sistemas operativos de las computadoras personales y los de las 
macrocomputadoras. 

8. Un archivo MINIX cuyo propietario tiene uid = 12 y gid = 1 tiene el modo rwxr-x—. Otro usuario con 
uid = 6, gid = 1 trata de ejecutar el archivo. ¿Qué sucede? 

9. En vista del hecho de que la simple existencia de un superusuario puede dar pie a todo tipo de proble¬ 
mas de seguridad, ¿por qué existe tal concepto? 

10. El modelo cliente-servidor es popular en los sistemas distribuidos. ¿Puede usarse también en los siste¬ 
mas de una sola computadora? 

11. ¿Por qué se necesita la tabla de procesos en un sistema de tiempo compartido? ¿Se necesita también en 
los sistemas de computadora personal, en los que sólo existe un proceso, el cual se apodera de toda la 
máquina hasta terminar? 

12. Señale la diferencia esencial que hay entre un archivo especial por bloques y un archivo especial por 
caracteres. 

13. En MINIX, si el usuario 2 se vincula con un archivo propiedad del usuario 1, y luego el usuario 1 
elimina el archivo, ¿qué sucede cuando el usuario 2 trata de leer el archivo? 
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14. ¿Por qué está limitada al superusuario la llamada al sistema CHROOT? (Sugerencia: Piense en los 
problemas de protección.) 

15. ¿Por qué tiene MINIX el programa update ejecutándose en segundo plano todo el tiempo? 

16. ¿Hay algún caso en que tenga sentido ignorar la señal SIGALRM? 

17. Escriba un programa (o una serie de programas) para probar todas las llamadas al sistema de MINIX. 
Para cada llamada, pruebe diversos conjuntos de parámetros, incluidos algunos incorrectos, para ver si son 
detectados. 

18. Escriba un shell similar al de la Fig. 1-10 pero que contenga suficiente código como para que funcione 
realmente y se pueda probar. También podrían agregársele algunas capacidades como redirección de 
entradas y salidas, conductos y trabajos en segundo plano. 
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PROCESOS 


Estamos a punto de emprender un estudio detallado de la forma en que se diseñan y construyen los 
sistemas operativos en general y MINIX en particular. El concepto central de cualquier sistema operativo 
es el proceso: una abstracción de un programa en ejecución. Todo lo demás gira alrededor de este 
concepto, y es importante que el diseñador (y el estudiante) de sistemas operativos sepa lo antes posible 
qué es un proceso. 


2,1 INTRODUCCIÓN A LOS PROCESOS 

Todas las computadoras modernas pueden hacer varias cosas al mismo tiempo. Mientras ejecuta un 
programa de usuario, una computadora también puede estar leyendo de un disco y enviando texto a una 
pantalla o impresora. En un sistema de multiprogramación, la CPU también conmuta de un programa a 
otro, ejecutando cada uno durante decenas o centenas de milisegundos. Si bien, estrictamente hablando, en 
un instante dado la CPU está ejecutando sólo un programa, en el curso de un segundo puede trabajar con 
varios programas, dando a los usuarios la ilusión de paralelismo. A veces se usa el término 
seudoparalelismo para referirse a esta rápida conmutación de la CPU entre programas, para distinguirla 
del verdadero paralelismo de hardware de los sistemas multiprocesador (que tienen dos o más CPU que 
comparten la misma memoria física). Para el ser humano es difícil seguir la pista a múltiples actividades 
paralelas. Por ello, los diseñadores de sistemas operativos han desarrollado a lo largo de los años un 
modelo (procesos secuenciales) que facilita el manejo del paralelismo. Ese modelo y sus usos son el tema 
de este capítulo. 
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2.1.1 El modelo de procesos 

En este modelo, todo el software ejecutable de la computadora, lo que a menudo incluye al sistema 
operativo, está organizado en una serie de procesos secuenciales, o simplemente procesos. 
Un proceso no es más que un programa en ejecución, e incluye los valores actuales del contador 
de programa, los registros y las variables. Conceptualmente, cada uno de estos procesos tiene su 
propia CPU virtual. Desde luego, en la realidad la verdadera CPU conmuta de un proceso a otro, 
pero para entender el sistema es mucho más fácil pensar en una colección de procesos que se 
ejecutan en (seudo) paralelo que tratar de seguir la pista a la forma en que la CPU conmuta de un 
programa a otro. Esta rápida conmutación se denomina multiprogramación, como vimos en el 
capítulo anterior. 

En la Fig. 2-l(a) vemos una computadora multiprogramando dos programas en la memoria. 
En la Fig. 2-l(b) vemos cuatro procesos, cada uno con su propio flujo de control (esto es, su 
propio contador de programa), ejecutándose con independencia de los otros. En la Fig. 2-l(c) 
vemos que si el intervalo de tiempo es suficientemente largo, todos los procesos avanzan, pero en 
un instante dado sólo un proceso se está ejecutando realmente. 



Figura 2-1. (a) Multiprogramación de cuatro programas, (b) Modelo conceptual de cuatro 
procesos secuenciales independientes, (c) Sólo un programa está activo en un instante dado. 


Con la CPU conmutando entre los procesos, la rapidez con que un proceso realiza sus cálculos 
no es uniforme, y probablemente ni siquiera reproducible si los mismos procesos se ejecutan otra 
vez. Por tanto, los procesos no deben programarse basándose en supuestos acerca de los tiempos. 
Considere, por ejemplo, un proceso de E/S que inicia una cinta continua para restaurar archivos 
respaldados, ejecuta un ciclo vacío 10 000 veces para permitir que la cinta alcance la velocidad 
de trabajo y luego emite un comando para leer el primer registro. Si la CPU decide conmutar a 
otro proceso durante el ciclo vacío, es posible que los procesos de cinta no se ejecuten otra vez 
sino hasta después de que el primer registro haya pasado por la cabeza de lectura. Cuando un 
proceso tiene requisitos de tiempo real críticos como éste, es decir, cuando ciertos eventos deben 
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ocurrir en cierto número de milisegundos, se deben tomar medidas especiales para asegurar que así 
ocurran. Normalmente, empero, los procesos no resultan afectados por la multiprogramación subyacente 
de la CPU ni las velocidades relativas de los diferentes procesos. 

La diferencia entre un programa y un proceso es sutil, pero crucial. Tal vez una analogía ayude a 
aclarar este punto. Consideremos un computólogo con inclinaciones gastronómicas que está preparando 
un pastel de cumpleaños para su hija. Él cuenta con una receta para pastel de cumpleaños y una cocina 
bien abastecida de las entradas necesarias: harina, huevos, azúcar, extracto de vainilla, etc. En esta 
analogía, la receta es el programa (es decir, un algoritmo expresado en alguna flotación apropiada), el 
computólogo es el procesador (CPU) y los ingredientes del pastel son los datos de entrada. El proceso es 
la actividad de nuestro pastelero consistente en leer la receta, obtener los ingredientes y hornear el pastel. 

Imaginemos ahora que el hijo del computólogo llega corriendo y llorando, diciendo que le picó una 
abeja. El computólogo registra el punto en que estaba en la receta (guarda el estado del proceso actual), 
saca un libro de primeros auxilios, y comienza a seguir las instrucciones que contiene. Aquí vemos cómo 
el procesador se conmuta de un proceso (hornear) a un proceso de más alta prioridad (administrar 
cuidados médicos), cada uno con un programa diferente (receta vs. libro de primeros auxilios). Una vez 
que se ha atendido la picadura de abeja, el computólogo regresa a su pastel, continuando en el punto 
donde había interrumpido. 

La idea clave aquí es que un proceso es una actividad de algún tipo: tiene programa, entrada, salida y 
un estado. Se puede compartir un procesador entre varios procesos, usando algún algoritmo de 
planificación para determinar cuándo debe dejarse de trabajar en un proceso para atender a uno distinto. 


Jerarquías de procesos 


Los sistemas operativos que manejan el concepto de proceso deben contar con algún mecanismo para 
crear todos los procesos necesarios. En los sistemas muy sencillos, o en los diseñados para ejecutar sólo 
una aplicación (p. ej., controlar un dispositivo en tiempo real), es posible que, cuan do el sistema se inicia, 
todos los procesos que puedan necesitarse estén presentes. Sin embargo, en la mayor parte de los sistemas 
se necesita algún mecanismo para crear y destruir procesos según sea necesario durante la operación. En 
MINIX, los procesos se crean con la llamada al sistema FORK (bifúrcar), que crea una copia idéntica del 
proceso invocador. El proceso hijo también puede ejecutar FORK, así que es posible tener un árbol de 
procesos. En otros sistemas operativos existen llamadas al sistema para crear un proceso, cargar su 
memoria y ponerlo a ejecutar. Sea cual sea la naturaleza exacta de la llamada al sistema, los procesos 
necesitan poder crear otros procesos. Observe que cada proceso tiene un padre, pero cero, uno, dos o más 
hijos. 

Como ejemplo sencillo del uso de los árboles de procesos, veamos la forma en que 
MINIX se inicializa a sí mismo cuando se pone en marcha. Un proceso especial, llamado mit, 
está presente en la imagen de arranque. Cuando este proceso comienza a ejecutarse, lee un archivo 
que le indica cuántas terminales hay, y luego bifúrca un proceso nuevo por terminal. Estos procesos 
esperan a que alguien inicie una sesión. Si un inicio de sesión (login) tiene éxito, el proceso de 
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inicio de sesión ejecuta un shell para aceptar comandos. Estos comandos pueden iniciar más procesos, y 
así sucesivamente. Por tanto, todos los procesos del sistema pertenecen a un mismo árbol, que tiene a mit 
en su raíz. (El código de mit no se lista en este libro, y tampoco el del shell. Había que poner un límite en 
algún lado.) 


Estados de procesos 


Aunque cada proceso es una entidad independiente, con su propio contador de programa y estado intemo, 
los procesos a menudo necesitan interactuar con otros procesos. Un proceso podría generar ciertas salidas 
que otro proceso utiliza como entradas. En el comando de shell 


cat capítulol capítulo2 capítulo3 grep árbol 


el primer proceso, que ejecuta cat, concatena y envía a la salida tres archivos. El segundo proceso, que 
ejecuta grep, selecciona todas las líneas que contienen la palabra “árbol”. Dependiendo de las velocidades 
relativas de los dos procesos (que a su vez dependen de la complejidad relativa de los programas y de 
cuánto tiempo de CPU ha ocupado cada uno), puede suceder que grep esté listo para ejecutarse, pero no 
haya entradas esperando ser procesadas por él. En tal caso, grep deberá bloquearse hasta que haya 
entradas disponibles. 

Cuando un proceso se bloquea, lo hace porque le es imposible continuar lógicamente, casi siempre 
porque está esperando entradas que todavía no están disponibles. También puede ser que un programa que 
conceptualmente está listo y en condiciones de ejecutarse sea detenido porque el sistema operativo ha 
decidido asignar la CPU a otro proceso durante un tiempo. Estas dos condiciones son totalmente distintas. 
En el primer caso, la suspensión es inherente al problema (no es posible procesar la línea de comandos del 
usuario antes de que éste la teclee). En el segundo caso, se trata de un tecnicismo del sistema (no hay 
suficientes CPU para darle a cada proceso su propio procesador privado). En la Fig. 2-2 vemos un 
diagrama de estados que muestra los tres estados en los que un proceso puede estar: 

1. Ejecutándose (usando realmente la CPU en ese instante). 

2. Listo (se puede ejecutar, pero se suspendió temporalmente para dejar que otro pro ceso se ejecute). 

3. Bloqueado (no puede ejecutarse en tanto no ocurra algún evento extemo). 

Lógicamente, los dos primeros estados son similares. En ambos casos el proceso está dispuesto a 
ejecutarse, sólo que en el segundo temporalmente no hay una CPU a su disposición. El tercer estado es 
diferente de los primeros dos en cuanto a que el proceso no puede ejecutarse, incluso si la CPU no tiene 
nada más que hacer. 

Puede haber cuatro transiciones entre estos tres estados, como se muestra. La transición 1 ocurre 
cuando un proceso descubre que no puede continuar. En algunos sistemas el proceso debe ejecutar una 
llamada al sistema, BLOCK, para pasar al estado bloqueado. En otros sistemas, incluido MINIX, cuando 
un proceso lee de un conducto o de un archivo especial (p. ej., una terminal) y no hay entradas 
disponibles, se bloquea automáticamente. 
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1. Un proceso se bloquea para aceptar entradas 

2. El planificador escoge otro proceso 

3. El planificador escoge este proceso 

4. Hay entradas disponibles 


Figura 2-2. Un proceso puede estar en el estado de ejecutándose, bloqueado o listo. Las 
transiciones entre estos tres estados son las que se muestran. 


Las tran s iciones 2 y 3 son causadas por el planificador de procesos, una parte del sistema operativo, 
sin que el proceso se entere siquiera de ellas. La transición 2 ocurre cuando el planificador decide que el 
proceso en ejecución ya se ejecutó durante suficiente tiempo y es hora de dejar que otros procesos tengan 
algo de tiempo de CPU. La transición 3 ocurre cuando todos los demás procesos han disfrutado de una 
porción justa y es hora de que el primer proceso reciba otra vez la CPU para ejecutarse. El tema de la 
planificación, es decir, de decidir cuál proceso debe ejecutarse cuándo y durante cuánto tiempo, es muy 
importante; lo exa mi naremos más adelante en este capítulo. Se han inventado muchos algoritmos para 
tratar de equilibrar las exigencias opuestas de eficiencia del sistema global y de equitatividad para los 
procesos individuales. 

La transición 4 ocurre cuando acontece el suceso externo que un proceso estaba esperando (como la 
llegada de entradas). Si ningún otro proceso se está ejecutando en ese instante, se dispara de inmediato la 
transición 3, y el proceso comienza a ejecutarse. En caso contrario, el proceso tal vez tenga que esperar en 
el estado listo durante cierto tiempo hasta que la CPU esté disponible. 

Usando el modelo de procesos, es mucho más fácil visualizar lo que está sucediendo dentro del 
sistema. Algunos de los procesos ejecutan programas que llevan a cabo comandos tecleados por un 
usuario. Otros procesos forman parte del sistema y se encargan de tareas tales como atender solicitudes de 
servicios de archivos o manejar los detalles de la operación de una unidad de disco o de cinta. Cuando 
ocurre una interrupción de disco, el sistema toma la decisión de dejar de ejecutar el proceso en curso y 
ejecutar el proceso de disco, que estaba bloqueado esperando dicha interrupción. Así, en lugar de pensar 
en interrupciones, podemos pensar en procesos de usuario, procesos de disco, procesos de terminal, etc., 
que se bloquean cuando están esperando que algo suceda. Cuando se ha leído el bloque de disco o se ha 
tecleado el carácter, el proceso que lo estaba esperando se desbloquea y es elegible para ejecutarse otra 
vez. 


Esta perspectiva da lugar al modelo que se muestra en la Fig. 2-3. Aquí, el nivel más bajo del 
sistema operativo es el planificador, con diversos procesos arriba de él. Todo el manejo de interrupciones 
y los detalles del inicio y la detención de procesos están ocultos en el planificador, que en realidad es muy 
pequeño. El resto del sistema operativo está estructurado en forma de procesos. El modelo de la Fig. 2-3 
se emplea en MINIX, con el entendido de que “planificador” no sólo se refiere a planificación de 
procesos, sino también a manejo de interrupciones y toda la comunicación entre procesos. No obstante, 
como una primera aproximación, sí muestra la estructura básica. 
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Figura 2*3. La capa más baja de un sistema operativo con estructura de procesos maneja 
las interrupciones y la planificación. Por encima de esa capa están los procesos secuenciales. 


2.1.2 Implementación de procesos 

Para implementar el modelo de procesos, el sistema operativo mantiene una tabla (un arreglo de 
estructuras) llamada tabla de procesos, con una entrada por cada proceso. Esta entrada contiene 
información acerca del estado del proceso, su contador de programa, el apuntador de pila, el reparto de 
memoria, la situación de sus archivos abiertos, su información de contabilidad y planificación y todos los 
demás aspectos de un proceso que se deben guardar cuando éste se conmuta del estado ejecutándose al 
estado listo, a fin de poder reiniciarlo después como si nunca se hubiera detenido. 

En MINIX la administración de procesos, de memoria y de archivos corren a cargo de módulos 
individuales dentro del sistema, por lo que la tabla de procesos se divide en particiones y cada módulo 
mantiene los campos que necesita. En la Fig. 2-4 se muestran algunos de los campos más importantes. Los 
campos de la primera colu mn a son los únicos pertinentes para este capítulo. Las otras dos columnas se 
incluyen sólo para dar una idea de qué información se necesita en otras partes del sistema. 

Ahora que hemos examinado la tabla de procesos, podemos explicar un poco más la forma de cómo 
se mantiene la ilusión de múltiples procesos secuenciales en una máquina con una CPU y muchos 
dispositivos de E/S. Lo que sigue es técnicamente una descripción de cómo funciona el “planificador” de 
la Fig. 2-3 en MINIX, pero la mayor parte de los sistemas operativos modernos funcionan básicamente de 
la misma manera. Cada clase de dispositivo de E/S (p. ej., discos flexibles, discos duros, cronómetros, 
terminales) tiene asociada una posición cerca de la base de la memoria llamada vector de interrupción 
que contiene la dirección del procedimiento de servicio de interrupciones. Supongamos que el proceso de 
usuario 3 se está ejecutando cuando ocurre una interrupción de disco, El hardware de interrupciones mete 
el contador de programa, la palabra de estado del programa y quizá uno o más registros en la pila (actual). 
A continuación, la computadora salta a la dirección especificada en el vector de interrupciones de disco. 
Esto es todo lo que el hardware hace. De aquí en adelante, el software decide lo que se hace. 

Lo primero que hace el procedimiento de servicio de interrupciones es guardar todos los registros 
de la entrada de tabla de procesos para el proceso actual. El número del proceso actual y un apuntador 
a su entrada de la tabla se guardan en variables globales a fin de poder encontrarlos rápidamente. 
Luego se saca de la pila la información depositada en ella por la interrupción, y se 
ajusta el apuntador de la pila de modo que apunte a una pila temporal empleada por el manejador 
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Administración de proce»o» 

Administración de memoria 

Administración de archivos 

Registros 

Apuntador al segmento de texto 

Máscara UMASK 

Contador de programa 

Apuntador al segmento de datos 

Directorio raíz 

Palabra de estado del programa 

Apuntador al segmento bss 

Directorio de trabajo 

Apuntador a la pila 

Estado de salida 

Descriptores de archivos 

Estado del proceso 

Estado de señales 

Uid efectivo 

Hora en que se Inició el proceso 

Identíficador del proceso 

Gid efectivo 

Tiempo de CPU usado 

Proceso padre 

Parámetros de llamadas al sistema 

Tiempo de CPU de los hifos 

Grupo de procesos 

Diversos bits de bandera 

Hora de la siguiente alarma 
Apuntadores a la cola de 
mensajes 

Bits de setales pendientes 
ktentíficador del proceso 

Diversos bits de bandera 

Uíd real 

Uid efectivo 

Gid real 

GkJ efectivo 

Mapas de brts para señales 
Diversos bits de bandera 



Figura 2-4. Algunos de los campos de la tabla de procesos de MINIX. 


de procesos. Las acciones como guardar los registros y ajustar el apuntador de la pila ni siquiera pueden 
expresarse en C, así que son realizadas por una pequeña rutina escrita en lenguaje de ensamblador. Una 
vez que esta rutina termina, invoca a un procedimiento en C para que se encargue del resto del trabajo. 

La comunicación entre procesos en MINIX se efectúa a través de mensajes, así que el siguiente paso 
consiste en construir un mensaje para enviarlo al proceso de disco, el cual estará bloqueado en espera de 
recibirlo. El mensaje dice que ocurrió una interrupción, a fin de distinguirlo de los mensajes de usuario 
que solicitan la lectura de bloques de disco y cosas por el estilo. Ahora se cambia el estado del proceso de 
disco de bloqueado a listo y se llama al planificador. En MINIX, los diferentes procesos tienen diferentes 
prioridades, con objeto de dar mejor servicio a los manejadores de dispositivos de E/S que a los procesos 
de usuario. Si el proceso de disco es ahora el proceso ejecutable con la prioridad más alta, se planificará 
para ejecutarse. Si el proceso que se interrumpió tiene la misma importancia o una mayor, se le planificará 
para ejecutarse otra vez, y e proceso de disco tendrá que esperar un poco. 

En cualquier caso, ahora regresa el procedimiento en C invocado por el código de interrupción en 
lenguaje de ensamblador, y este código carga los registros y el mapa de memoria para el proceso que 
ahora es el actual, y lo pone en marcha. El manejo de interrupciones y la planificación se resumen en la 
Fig. 2-5. Vale la pena señalar que los detalles varían un poco de un sistema a otro. 


2.1.3 Hilos 

En un proceso tradicional del tipo que acabamos de estudiar hay un solo hilo de control y un solo 
contador de programa en cada proceso. Sin embargo, algunos sistemas operativos modernos 
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1. El hardware agrega a la pila el contador de programa, etc. 

2. El hardware carga un nuevo contador de programa del vector de interrupciones. 

3. Ei procedimiento en lenguaje ensamblador guarda los registros. 

4. El procedimiento en lenguaje ensamblador prepara una nueva pila. 

5. Se ejecuta el servicio de Interrupciones en C (por lo regular lee y coloca en buffers las entradas) 

6. El planificador marca la tarea en espera como lista. 

7. El planificador decide cuál proceso debe ejecutarse a continuación 

8. El procedimiento en C regresa al código en ensamblador. 

9. El procedimiento en lenguaje ensamblador inicia el nuevo proceso actual. 


Figura 2-5. Bosquejo de lo que el nivel más bajo del sistema operativo hace cuando ocurre 
una interrupción. 


manejan múltiples hilos de control dentro de un proceso. Estos hilos de control normalmente se llaman 
sólo hilos u, ocasionalmente, procesos ligeros. 

En la Fig. 2-6(a) vemos tres procesos tradicionales. Cada proceso tiene su propio espacio de 
direcciones y un solo hilo de control. En contraste, en la Fig. 2-6(b) vemos un solo proceso con tres hilos 
de control. Aunque en ambos casos tenemos tres hilos, en la Fig. 2-6(a) cada uno de ellos opera en un 
espacio de direcciones distinto, en tanto que en la Fig. 2-6(b) los tres comparten el mismo espacio de 
direcciones. 


Computadora Computadora 



Como ejemplo de situación en la que podrían usarse múltiples hilos, consideremos un proceso 
servidor de archivos que recibe solicitudes para leer y escribir archivos y devuelve los datos solicitados o 
acepta datos actualizados. A fin de mejorar el rendimiento, el servidor mantiene un caché de archivos 
recientemente usados en la memoria, leyendo del caché y escribiendo en él siempre que es posible. 

Esta situación se presta bien al modelo de la Fig. 2.6(b). Cuando llega una solicitud, se le 
entrega a un hilo para que la procese. Si ese hilo se bloquea en algún momento esperando una 
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transferencia de disco, los demás hilos aún pueden ejecutarse, de modo que el servidor puede seguir 
procesando nuevas solicitudes incluso mientras se está efectuando E/S de disco. En cambio, el modelo de 
la Fig. 2-6(a) no es apropiado, porque es indispensable que todos los hilos del servidor de archivos tengan 
acceso al mismo caché, y los tres hilos de la Fig. 2-6(a) no comparten el mismo espacio de direcciones y, 
por tanto, no pueden compartir el mismo caché en memoria. 

Otro ejemplo de caso en el que son útiles los hilos es el de los navegadores de la World Wide Web, 
como Netscape y Mosaic. Muchas páginas Web contienen múltiples imágenes pequeñas. Para cada 
imagen de una página Web, el navegador debe establecer una conexión individual con el sitio de la página 
de casa y solicitar la imagen. Se desperdicia una gran cantidad de tiempo estableciendo y liberando todas 
estas conexiones. Si tenemos múltiples hilos dentro del navegador, podemos solicitar muchas imágenes al 
mismo tiempo, acelerando considerablemente el rendi mi ento en la mayor parte de los casos, ya que en el 
caso de imágenes pequeñas el tiempo de preparación es el factor limitante, no la rapidez de la línea de 
transmisión. 

Cuando están presentes múltiples hilos en el mismo espacio de direcciones, algunos de los campos de 
la Fig. 2-4 no contienen información para cada proceso, sino para cada hilo, así que se necesita una tabla 
de hilos aparte, con una entrada por hilo. Entre los elementos que son distintos para cada hilo están el 
contador de programa, los registros y el estado. El contador de programa se necesita porque los hilos, al 
igual que los procesos, pueden suspenderse y reanudarse. Los registros se necesitan porque cuando los 
hilos se suspenden sus registros deben guardarse. Por último, los hilos, al igual que los procesos, pueden 
estar en los estados de ejecutándose, listo o bloqueado. 

En algunos sistemas el sistema operativo no está consciente de la existencia de los hilos. En otras 
palabras, los hilos se manejan totalmente en el espacio de usuario. Por ejemplo, cuando un hilo está a 
punto de bloquearse, escoge e inicia a su sucesor antes de detenerse. Hay varios paquetes de hilos a nivel 
de usuario, incluidos los paquetes de hilos P de POSIX e hilos C de Mach. 

En otros sistemas, el sistema operativo está consciente de la existencia de múltiples hilos por 
proceso, así que, cuando un hilo se bloquea, el sistema operativo escoge el que se ejecutará a 
continuación, ya sea del mismo proceso o de uno distinto. Para realizar la planificación, el kemel debe 
tener una tabla de hilos que liste todos los hilos del sistema, análoga a la tabla de procesos. 

Aunque estas dos alternativas pueden parecer equivalentes, su rendimiento es muy distinto. La 
conmutación de hilos es mucho más rápida cuando la administración de hilos se efectúa en el espacio de 
usuario que cuando se necesita una llamada al kemel. Este hecho es un argumento convincente para 
realizar la administración de hilos en el espacio de usuario. Por otro lado, cuando los hilos se manejan 
totalmente en el espacio de usuario y uno se bloquea (p. ej., esperando E/S o que se maneje una falla de 
página), el kemel bloquea todo el proceso, ya que no tiene idea de que existen otros hilos. Este hecho es 
un argumento importante en favor de realizar la administración de hilos en el kemel. La consecuencia es 
que se usan ambos sistemas; además, se han propuesto diversos esquemas híbridos (Anderson et al., 
1992). 

Sea que los hilos sean administrados por el kemel o en el espacio de usuario, introducen una serie de 
problemas que deben resolverse y que modifican sustancialmente el modelo de programación. Para 
comenzar, consideremos los efectos de la llamada al sistema FORK. Si el proceso padre tiene múltiples 
hilos, ¿debe tenerlos también el hijo? Si no, es posible que el proceso no fúncione correctamente, ya que 
es posible que todos ellos sean esenciales. 
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Por otro lado, si el proceso hijo obtiene tantos hilos como el padre, ¿qué sucede si un hilo estaba 
bloqueado en una llamada READ de, digamos, el teclado. ¿Hay ahora dos hilos bloqueados esperando el 
teclado? Si se teclea una línea, ¿reciben ambos hilos una copia de ella? ¿Sólo el padre? ¿Sólo el hijo? El 
mismo problema ocurre con las conexiones de red abiertas. 

Otra clase de problemas tiene que ver con el hecho de que los hilos comparten muchas estructuras de 
datos. ¿Qué sucede si un hilo cierra un archivo mientras otro todavía lo está leyendo? Supongamos que un 
hilo se da cuenta de que hay muy poca memoria y comienza a asignar más memoria. Luego, antes de que 
ter mi ne de hacerlo, ocurre una conmutación de hilo, y el nuevo hilo también se da cuenta de que hay 
demasiada poca memoria y comienza a asignar más memoria. ¿La asignación ocurre una sola vez o dos? 
En casi todos los sistemas que no se diseñaron pensando en hilos, las bibliotecas (como el procedimiento 
de asignación de memoria) no son reentrantes, y se caen si se emite una segunda llamada mientras la 
primera todavía está activa. 

Otro problema se relaciona con los informes de error. En UNIX, después de una llamada al sistema, 
la situación de la llamada se coloca en una variable global, ermo. ¿Qué sucede si un hilo efectúa una 
llamada al sistema y, antes de que pueda leer ermo, otro hilo realiza una llamada al sistema, borrando el 
valor original? 

Consideremos ahora las señales. Algunas señales son lógicamente específicas para cada hilo, en tanto 
que otras no lo son. Por ejemplo, si un hilo invoca ALARM, tiene sentido que la señal resultante se envíe 
al hilo que efectuó la llamada. Si el kemel está consciente de la existencia de hilos, normalmente puede 
asegurarse de que el hilo correcto reciba la señal. Si el kemel no sabe de los hilos, el paquete de hilos de 
alguna forma debe seguir la pista a las alarmas. Surge una complicación adicional en el caso de hilos a 
nivel de usuario cuando (como sucede en UNIX) un proceso sólo puede tener una alarma pendiente a la 
vez y varios hilos pueden invocar ALARM independientemente. 

Otras señales, como una interrupción de teclado, no son específicas para un hilo. ¿Quién deberá 
atraparlas? ¿Un hilo designado? ¿Todos los hilos? ¿Un hilo recién creado? Todas estas soluciones tienen 
problemas. Además, ¿qué sucede si un hilo cambia los manejadores de señales sin avisar a los demás 
hilos’? 

Un último problema introducido por los hilos es la administración de la pila. En muchos sistemas, 
cuando hay un desbordamiento de pila, el kemel simplemente amplía la pila automáticamente. Cuando un 
proceso tiene varios hilos, también debe tener varias pilas. Si el kemel no tiene conocimiento de todas 
estas pilas, no podrá hacerlas crecer automáticamente cuando haya una falla de pila. De hecho, es posible 
que el kemel ni siquiera se dé cuenta de que la falla de memoria está relacionada con el crecimiento de 
una pila. 

Estos problemas ciertamente no son insuperables, pero sí ponen de manifiesto que la simple 
introducción de hilos en un sistema existente sin un rediseño sustancial del sistema no funcionará. Cuando 
menos, es preciso redefinir la semántica de las llamadas al sistema y reescribir las bibliotecas. Además, 
todas estas cosas deben hacerse de modo tal que sigan siendo compatibles hacia atrás con los programas 
existentes para el caso limitante de un proceso con un solo hilo. Si desea información adicional acerca de 
los hilos, véase (Hauser et al., 1993; y Marsh et al., 1991), 
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Los procesos con frecuencia necesitan comunicarse con otros procesos. Por ejemplo, en un conducto de 
shell, la salida del primer proceso debe pasarse al segundo proceso, y así sucesiva mente. Por tanto, es 
necesaria la comunicación entre procesos, de preferencia en una forma bien estructurada que no utilice 
interrupciones. En las siguientes secciones examinaremos algunos de los problemas relacionados con esta 

comunicación entre procesos o IPC. 

En pocas palabras, tenemos tres problemas. Ya hicimos alusión al primero de ellos: ¿cómo puede un 
proceso pasar información a otro? El segundo tiene que ver con asegurarse de que dos o más procesos no 
se estorben mutuamente al efectuar actividades críticas (suponga que dos procesos tratan de apoderarse al 
mismo tiempo de los últimos 100K de memoria). El tercero se relaciona con la secuencia correcta cuando 
existen dependencias: Si el proceso A produce datos y el proceso B los imprime, B tiene que esperar hasta 
que A haya producido algunos datos antes de comenzar a imprimir. Examinaremos estos tres problemas a 
partir de la siguiente sección. 


2.2.1 Condiciones de competencia 

En algunos sistemas operativos, los procesos que están colaborando podrían compartir cierto 
almacenamiento común en el que ambos pueden leer y escribir. El almacenamiento compartido puede 
estar en la memoria principal o puede ser un archivo compartido; la ubicación de la memoria compartida 
no altera la naturaleza de la comunicación ni los problemas que surgen. Para ver cómo funciona la 
comunicación entre procesos en la práctica, consideremos un ejemplo sencillo pero común, un spooler de 
impresión. Cuando un proceso desea imprimir un archivo, introduce el nombre del archivo en un 
directorio de spooler especial. Otro proceso, el demonio de impresión, revisa periódicamente el 
directorio para ver si hay archivos por imprimir, y silos hay los imprime y luego borra sus nombres del 
directorio. 

Imagine que nuestro directorio de spooler tiene un número elevado (potencialmente infinito) de 
ranuras, numeradas 0, 1, 2, ..., cada una con capacidad para un nombre de archivo. Imagine además que 
hay dos variables compartidas, out, que apuntan al siguiente archivo por imprimir, e in, que apunta a la 
siguiente ranura libre del directorio. Estas dos variables bien podrían guardarse en un archivo de dos 
palabras que estuviera accesible para todos los procesos. En un instante dado, las ranuras O a 3 están 
vacías (los archivos ya se imprimieron) y las ranuras 4 a 6 están llenas (con los nombres de archivos en 
cola para imprimirse). En forma más o menos simultánea, los procesos A y B deciden que desean poner en 
cola un archivo para impresión. Esta situación se muestra en la Fig. 2-7. 

En las jurisdicciones en las que aplica la ley de Murphy, podría ocurrir lo siguiente. El proceso 
A lee in y almacena su valor, 7, en una variable local llamada siguiente ranura libre. Justo en 
ese momento ocurre una interrupción de reloj y la CPU decide que el proceso A ya se 
ejecutó durante suficiente tiempo, así que conmuta al proceso B. El proceso B también lee in, y 


+ Si algo puede salir mal, saldrá mal. 
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Directorio 
de spooler 



Figura 2-7. Dos procesos quieren acceder a memoria compartida al mismo tiempo. 


también obtiene un 7, así que almacena el nombre de su archivo en la ranura 7 y actualiza in con el valor 
8. Luego se va y hace otras cosas. 

Tarde o temprano, el proceso A se ejecuta otra vez, continuando en donde se interrumpió. A 
examina siguienteranuralibre, encuentra 7 ahí, y escribe su nombre de archivo en la ranura 7, borrando 
el nombre que el proceso B acaba de poner ahí. Luego A calcula siguiente ranura libre + 1, que es 8, y 
asigna 8 a in. El directorio de spooler no tiene contradicciones intemas, así que el demonio de impresión 
no notará que algo esté mal, si bien el proceso B nunca obtendrá sus salidas. Situaciones como ésta, en la 
que dos o más procesos leen o escriben datos compartidos y el resultado final depende de quién se ejecuta 
precisamente cuándo, se denominan condiciones de competencia. La depuración de programas que 
contienen condiciones de competencia no es nada divertida. Los resultados de la mayor parte de las 
pruebas son correctos, pero de vez en cuando algo raro e inexplicable sucede. 


2.2.2 Secciones críticas 

¿Cómo evitamos las condiciones de competencia? La clave para evitar problemas en ésta y muchas otras 
situaciones en las que se comparte memoria, archivos o cualquier otra cosa es encontrar una forma de 
prohibir que más de un proceso lea y escriba los datos compartidos al mismo tiempo. Dicho de otro modo, 
lo que necesitamos es exclusión mutua: alguna forma de asegurar que si un proceso está usando una 
variable o archivo compartido, los otros procesos quedarán excluidos de hacer lo mismo. El problema 
anterior ocurrió porque el proceso B comenzó a usar una de las variables compartidas antes de que A 
terminara de usarla. La selección de operaciones primitivas apropiadas para lograr la exclusión mutua es 
un aspecto importante del diseño de cualquier sistema operativo, y un tema que examinaremos con gran 
detalle en las siguientes secciones. 

El problema de evitar condiciones de competencia también puede formularse de manera 
abstracta. Una parte del tiempo, un proceso está ocupado realizando cálculos intemos y otras 
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cosas que no dan pie a condiciones de competencia. Sin embargo, hay veces en que un proceso está 
accediendo a memoria o archivos compartidos, o efectuando otras tareas críticas que pueden dar lugar a 
competencias. Esa parte del programa en la que se accede a la memoria compartida se denomina región 
crítica o sección crítica. Si pudiéramos organizar las cosas de modo que dos procesos nunca pudieran 
estar en sus regiones críticas al mismo tiempo, podríamos evitar las condiciones de competencia. 

Aunque este requisito evita las condiciones de competencia, no es suficiente para lograr que los 
procesos paralelos cooperen de manera correcta y eficiente usando datos compartidos. Necesitamos que se 
cumplan cuatro condiciones para tener una buena solución: 

1. Dos procesos nunca pueden estar simultáneamente dentro de sus regiones críticas. 

2. No puede suponerse nada acerca de las velocidades o el número de las CPU. 

3. Ningún proceso que se ejecute fúera de su región crítica puede bloquear a otros procesos. 

4. Ningún proceso deberá tener que esperar indefinidamente para entrar en su región crítica. 


2.2.3 Exclusión mutua con espera activa 


En esta sección examinaremos varias propuestas para lograr la exclusión mutua, de modo que cuando un 
proceso esté ocupado actualizando la memoria compartida en su región crítica, ningún otro proceso entre 
en su región crítica y cause problemas. 


Inhabilitación de interrupciones 

La solución más sencilla es hacer que cada proceso inhabilite las interrupciones justo después de ingresar 
en su región crítica y vuelva a habilitarlas justo antes de salir de ella. Con las interrupciones inhabilitadas, 
no pueden ocurrir interrupciones de reloj. Después de todo, la CPU sólo se conmuta de un proceso a otro 
como resultado de interrupciones de reloj o de otro tipo, y con las interrupciones desactivadas la CPU no 
se conmutará a ningún otro proceso. Así, una vez que un proceso ha inhabilitado las interrupciones, puede 
examinar y actualizar la memoria compartida sin temor a que otro proceso intervenga. 

Este enfoque casi nunca resulta atractivo porque no es prudente conferir a los procesos de usuario la 
facultad de desactivar las interrupciones. Supongamos que uno de ellos lo hiciera, y nunca habilitara las 
interrupciones otra vez. Esto podría terminar con el sistema. Además, si el sistema es multiprocesador, con 
dos o más CPU, la inhabilitación de las interrupciones afectaría sólo a la CPU que ejecutara la instrucción 
de inhabilitación; las demás seguirían ejecutándose y podrían acceder a la memoria compartida. 

Por otro lado, en muchos casos es necesario que el kemel mismo inhabilite las 
interrupciones durante unas cuantas instrucciones mientras actualiza variables o listas. Si 
ocurriera una interrupción en un momento en que la lista de procesos listos, por ejemplo, está en un estado 
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inconsistente, ocurrirían condiciones de competencia. La conclusión es: la inhabilitación de interrupciones 
suele ser una técnica útil dentro del sistema operativo mismo pero no es apropiada como mecanismo de 
exclusión mutua general para los procesos de usuario. 


Variables de candado 

Veamos ahora una posible solución de software. Supongamos que tenemos una sola variable (de candado) 
compartida cuyo valor inicial es 0. Cuando un proceso quiere entrar en su región crítica, lo primero que 
hace es probar el candado. Si el candado es O, el proceso le asigna 1 y entra en su región crítica; si es 1, el 
proceso espera hasta que el candado vuelve a ser O. Así, un O significa que ningún proceso está en su 
región crítica, y un 1 significa que algún proceso está en su región crítica. 

Desafortunadamente, esta idea contiene exactamente el mismo defecto fatal que v im os en el 
directorio de spooler. Supongamos que un proceso lee el candado y ve que es O. Antes de que este 
proceso pueda asignar 1 al candado, se planifica otro proceso, el cual se ejecuta y asigna 1 al candado. 
Cuando el primer proceso continúa su ejecución, asignará 1 al candado, y dos procesos estarán en su 
región crítica al mismo tiempo. 

Podríamos pensar que este problema puede superarse leyendo primero el valor del candado, y 
verificándolo otra vez justo antes de guardar el 1 en él, pero esto no sirve de nada. La competencia 
ocurriría entonces si el segundo proceso modifica el candado justo después de que el primer proceso 
terminó su segunda verificación. 


Alternancia estricta 

Una tercera estrategia para abordar el problema de la exclusión mutua se muestra en la Fig. 2-8. Este 
fragmento de programa, como casi todos los del libro, está escrito en C. Se escogió C aquí porque los 
sistemas operativos reales con frecuencia se escriben en C (u ocasionalmente en C++), pero casi nunca en 
lenguajes como Modula 2 o Pascal. 


while (TRUE) { 
while(tum != 0) f esperar V; 
criticaUregionO; 
tum = 1; 

noncrit¡cal_reg*on(): 

) 

(a) 


while (TRUE) { 
while(turn != 1) /* esperar 7; 
critlcal_regton(); 
tum * 0; 

noocritical_reg»on(); 

} 

(b) 


Figura 2-8. Solución propuesta para el problema de la región critica. 


En la Fig. 2-8, la variable interna tum, que inicialmente es O, indica a quién le toca entrar en la 
región crítica y examinar o actualizar la memoria compartida. En un principio, el proceso O 


SEC. 2.2 


COMUNICACIÓN ENTRE PROCESOS 


61 


inspecciona tum, ve que es O, y entra en su región crítica. El proceso 1 también ve que tum es O y se 
mantiene en un ciclo corto probando tum continuamente para detectar el momento en que cambia a 1. Esta 
prueba continua de una variable hasta que adquiere algún valor se denomina espera activa, y 
normalmente debe evitarse, ya que desperdicia tiempo de CPU. La espera activa sólo debe usarse cuando 
exista una expectativa razonable de que la espera será corta. 

Cuando el proceso O sale de la región crítica, asigna 1 a tum, a fin de que el proceso 1 pueda entrar 
en su región crítica. Supongamos que el proceso 1 ter mi na su región crítica rápidamente, de modo que 
ambos procesos están en sus regiones no críticas, y tum vale O. Ahora el proceso O ejecuta su ciclo 
completo rápidamente, regresando a su región no crítica después de haber asignado 1 a tum. Luego, el 
proceso O termina su región no crítica y regresa al principio de su ciclo. Desafortunadamente, no puede 
entrar en su región crítica porque tum es 1 y el proceso 1 está ocupado en su región no crítica. Dicho de 
otro modo, la alternancia de tumos no es una buena idea cuando un proceso es mucho más lento que el 
otro. 


Esta situación viola la condición 3 antes mencionada: el proceso O está siendo bloqueado por un 
proceso que no está en su región crítica. Volviendo al ejemplo del directorio de spooler, si ahora 
asociamos la región crítica a las actividades de leer y escribir el directorio de spooler, el proceso O no 
podría imprimir otro archivo porque el proceso 1 está haciendo alguna otra cosa. 

De hecho, esta solución requiere que los dos procesos se alternen estrictamente en el ingreso a sus 
regiones críticas, por ejemplo, al poner archivos en spool. Ningún proceso podría poner en spool dos 
archivos seguidos. Si bien este algoritmo evita todas las competencias, no es en realidad un candidato 
serio para ser una solución porque viola la condición 3. 


Solución de Peterson 

Combinando la idea de tomar tumos con la de tener variables de candado y variables de advertencia, un 
matemático holandés, T. Dekker, inventó una solución de software para el problema de la exclusión mutua 
que no requiere una alternancia estricta. Si desea una explicación del algoritmo de Dekker, véase 
(Dijkstra, 1965). 

En 1981, G. L. Peterson descubrió una forma mucho más sencilla de lograr la exclusión mutua, 
haciendo obsoleta la solución de Dekker. El algoritmo de Peterson se muestra en la Fig. 2-9, y consiste en 
dos procedimientos escritos en ANSI C, lo que implica que se deben proporcionar prototipos de fúnción 
para todas las fúnciones que se definen y usan. Sin embargo, a fin de ahorrar espacio, no mostraremos los 
prototipos en este ejemplo ni en los que siguen. 

Antes de usar las variables compartidas (es decir, antes de entrar en su región crítica), cada proceso 
invoca enterregion (entrar en región) con su propio número de proceso, 0 o 1, como parámetro. Esta 
invocación lo obligará a esperar, si es necesario, hasta que pueda entrar sin peligro. Después de haber 
terminado de manipular las variables compartidas, el proceso invoca leave region (salir de región) para 
indicar que ya terminó y permitir que el otro proceso entre si lo desea. 

Veamos cómo fúnciona esta solución. En un principio ninguno de los procesos está en su región 
crítica. Ahora el proceso O invoca enter region, e indica su interés asignando TRUE a su elemento del 
arreglo interested (interesado) y asignando tum a O. Puesto que el proceso 1 no está interesado, 
enter region regresa de inmediato. Si ahora el proceso 1 invoca enter region, 



62 


PROCESOS 


CAP. 2 


¿define FALSE 0 

¿define TRUE 1 

¿define N 2 


/* número de procesos 7 


int tum; 

int ¡nterested[N]; 


r ¿a quién le toca? 7 

/* todos los valores son inicialmente 0 (FALSE) 7 


void enter_region(int process); 

{ 

int other; 


r proceso 0 o 1 7 
r número del otro proceso 7 


other = 1 - process; /* 

interested(process) = TRUE; /* 

tum = process; r 

whüe (tum == process && interested(other) 


lo opuesto de process 7 
mostrar interés 7 
establecer bandera 7 
== TRUE) r instrucción nula 7; 


> 


void leave_region(int process) r process: quién sale 7 

{ 

interested(process) = FALSE; /* indicar salida de la región critica 7 

> 

Figura 2-9. Solución de Pcterson para lograr la exclusión mutua. 


permanecerá dando vueltas en su ciclo hasta que se asigne FALSE a inte res ted[0], cosa que sólo sucede 
cuando el proceso O invoca leave region para salir de su región crítica. 

Consideremos ahora el caso en que ambos procesos invocan enter region casi simultáneamente. 
Ambos almacenarán su número de proceso en tum, pero el único que cuenta es el que se almacena 
después; el primero se pierde. Supongamos que el proceso 1 es el segundo en almacenar su número de 
proceso, así que tum vale 1. Cuando ambos procesos llegan a la instrucción while, el proceso 0 lo ejecuta 
cero veces e ingresa en su región crítica. El proceso 1 da vueltas en el ciclo y no entra en su región crítica. 


La instrucción TSL 

Examinemos ahora una propuesta que requiere un poco de ayuda del hardware. Muchas computadoras, 
sobre todo las diseñadas pensando en múltiples procesadores, tienen una instrucción TEST AND SET 
LOCK (TSL, probar y fijar candado) que fúnciona como sigue. La instrucción lee el contenido de la 
palabra de memoria, lo coloca en un registro y luego almacena un valor distinto de cero en esa dirección 
de memoria. Se garantiza que las operaciones de leer la palabra y guardar el valor en ella son indivisibles; 
ningún otro procesador puede acceder a la palabra de memoria en tanto la instrucción no haya terminado. 
La CPU que ejecuta la instrucción TSL pone un candado al bus de memoria para que ninguna otra CPU 
pueda acceder a la memoria en tanto no ter mi ne. 
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Para usar la instrucción TSL, creamos una variable compartida, lock, a fin de coordinar el acceso a la 
memoria compartida. Cuando lock es 0, cualquier proceso puede asignarle 1 usando la instrucción TSL y 
luego leer o escribir la memoria compartida. Cuando el proceso termina, asigna otra vez O a lock usando 
una instrucción MOVE ordinaria. 

¿Cómo podemos usar esta instrucción para evitar que dos procesos entren simultáneamente en sus 
regiones críticas? La solución se da en la Fig. 2-10. Ahí se muestra una subrutina de cuatro instrucciones 
escrita en un lenguaje ensamblador ficticio (pero típico). La primera instrucción copia el valor antiguo de 
lock en el registro y luego asigna 1 a lock. Luego se compara el valor antiguo con 0. Si es distinto de cero, 
el candado ya estaba establecido, así que el programa simplemente vuelve al principio y lo prueba otra 
vez. Tarde o temprano el valor de lock será O (cuando el proceso que actualmente está en su región crítica 
termine con lo que está haciendo dentro de dicha región) y la subrutina regresará, con el candado 
establecido. Liberar el candado es sencillo, pues basta con almacenar O en lock. No se requieren 
instrucciones especiales. 

enter región: 

tsl register.lock 
cmp register,#0 
jne enter_region 
ret 


I copiar lock en register y asignarle 1 
I ¿era lock 0? 

I si no era cero, se asignó 1 a lock, y se ejecuta el ciclo 
I volver al ¡nvocador; se entró en la región critica 


leave_region: 

move lock,#0 
ret 


I guardar un 0 en lock 
I volver al invocador 


Figura 2-10. Establecimiento y liberación de candados con TSL. 


Ya tenemos una solución al problema de la región crítica que es directa. Antes de entrar en su región 
crítica, un proceso invoca enterregion, la cual realiza espera activa hasta que el candado está libre; luego 
adquiere el candado y regresa. Después de la región crítica el proceso invoca leaveregion, que almacena 
un O en lock. Al igual que todas las soluciones basadas en regiones críticas, el proceso debe invocar 
enter region y leave region en los momentos correctos para que el método funcione. Si un proceso hace 
trampa, la exclusión mutua fallará. 


2.2.4 Dormir y despertar 

Tanto la solución de Peterson como la que usa TSL son correctas, pero ambas tienen el defecto de requerir 
espera activa. En esencia, lo que estas soluciones hacen es lo siguiente: cuando un proceso desea entrar en 
su región crítica verifica si está permitida la entrada; si no, el proceso simple mente repite un ciclo corto 
esperando hasta que lo esté. 

Este enfoque no sólo desperdicia tiempo de CPU, sino que también puede tener efectos 
inesperados. Consideremos una computadora con dos procesos, H, de alta prioridad, y L, de baja 
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prioridad. Las reglas de planificación son tales que H se ejecuta siempre que está en el estado listo. En un 
momento dado, con L en su región crítica, H queda listo para ejecutarse (p. ej., se completa una operación 
de E/S). H inicia ahora la espera activa, pero dado que L nunca se planifica mientras H se está ejecutando, 
L nunca tiene oportunidad de salir de su región crítica, y H permanece en un ciclo infinito. Esta situación 
se conoce como problema de inversión de prioridad. 

Examinemos ahora algunas primitivas de comunicación entre procesos que se bloquean en lugar de 
desperdiciar tiempo de CPU cuando no se les permite entrar en sus regiones críticas. Una de las más 
sencillas es el par SLEEP y WAKEUP. SLEEP (dormir) es una llamada al sistema que hace que el 
invocador se bloquee, es decir, se suspenda hasta que otro proceso lo despierte. La llamada WAKEUP 
(despertar) tiene un parámetro, el proceso que se debe despertar. Como alternativa, tanto SLEEP como 
WAKEUP pueden tener un parámetro cada uno, una dirección de memoria que sirve para enlazar los 
SLEEP con los WAKEUP. 


El problema de productor-consumidor 

Como ejemplo de uso de estas primitivas, consideremos el problema de productor-consumidor (también 
conocido como problema del buffer limitado). Dos procesos comparten un mismo buffer de tamaño fijo. 
Uno de ellos, el productor, coloca información en el buffer, y el otro, el consumidor, la saca. (También es 
posible generalizar el problema a m productores y n consumidores, pero sólo consideraremos el caso de un 
productor y un consumidor porque esto simplifica las soluciones.) 

Surgen problemas cuando el productor quiere colocar un nuevo elemento en el buffer, pero éste ya 
está lleno. La solución es que el productor se duerma y sea despertado cuando el consumidor haya retirado 
uno o más elementos. De forma similar, si el consumidor desea sacar un elemento del buffer y ve que está 
vacío, se duerme hasta que el productor pone algo en el buffer y lo despierta. 

Este enfoque parece muy sencillo, pero da lugar a los mismos tipos de condiciones de competencia 
que vimos antes con el directorio de spooler. Para seguir la pista al número de elementos contenidos en el 
buffer, necesitaremos una variable, count. Si el número máximo de elementos que el buffer puede 
contener es N, el código del productor primero verificará si count es igual a N. Si es así, el productor se 
dormirá; si no, el productor agregará un elemento e incrementará count. 

El código del consumidor es similar: primero se prueba count para ver si es O. Si así es, el 
consumidor se duerme; si no, el consumidor saca un elemento y decrementa el contador. Cada uno de 
estos procesos verifica también si el otro debería estar durmiendo, y si no es así, lo despierta. El código 
del productor y del consumidor se muestra en la Fig. 2-11, 

Para expresar las llamadas al sistema como SLEEP y WAKEUP en C, las mostraremos como 
llamadas a rutinas de biblioteca. Éstas no forman parte de la biblioteca estándar de C, pero es de suponer 
que estarían disponibles en cualquier sistema que realmente tuviera esas llamadas al sistema. Los 
procedimientos enteritem (colocar elemento) y removeitem (retirar elemento), que no se muestran, se 
encargan de la contabilización de la colocación de elementos en el buffer y el retiro de elementos de él. 
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#define N 100 
•ni count = 0; 

void producer(void) 

{ 

while (TRUE) { 

produce_rtem(); 
if (count = N) sleep(); 
enter_item(); 
count = count + 1; 

íf (count == 1) wakeup(consumer); 

) 

) 


r número de ranuras del buffer 7 
r número de elementos en el buffer 7 


/* repetir indefinidamente 7 
r generar el siguiente elemento 7 
/* si el buffer está lleno, dormir 7 
/* colocar elemento en el buffer 7 
r incrementar la cuenta de elementos 
en el buffer 7 

r ¿estaba vacío el buffer? 7 


void consumer(void) 

{ 

while (TRUEM 

if (count == 0) sleep(); 
removeJtem(); 
counl = count-1; 

if (count == N-1) wakeup(producer); 
consume _item(); 

) 

} 


r repetir indefinidamente 7 
r si el buffer está vacío, dormir 7 
r remover elemento del buffer 7 
/* decrementar la cuenta de elementos 
en el buffer 7 

/* ¿estaba lleno el buffer? 7 
/* imprimir elemento 7 


Figura 2-11. F.l problema de productor-consumidor con una condición de competencia fatal. 


Volvamos ahora a la condición de competencia. Ésta puede ocurrir porque el acceso a count es 
inestricto, y podría presentarse la siguiente situación. El buffer está vacío y el consumidor acaba de leer 
count para ver si es O. En ese instante, el planificador decide dejar de ejecutar el consumidor 
temporalmente y comenzar a ejecutar el productor. Éste coloca un elemento en el buffer, incrementa 
count, y observa que ahora vale 1. Esto implica que antes count valía O, y por ende que el consu mi dor está 
durmiendo, así que el productor invoca wakeup para despertar al consumidor. 

Desafortunadamente, el consumidor todavía no está dormido lógicamente, de modo que la señal de 
despertar se pierde. Cuando el consumidor reanuda su ejecución, prueba el valor de count que había leído 
previamente, ve que es O y se duerme. Tarde o temprano el productor llenará el buffer y se dormirá. 
Ambos seguirán durmiendo eternamente. 

La esencia del problema aquí es que se perdió una llamada enviada para despertar a un proceso que 
(todavía) no estaba dormido. Si no se perdiera, todo funcionaría. Una compostura rápida consiste en 
modificar las reglas y agregar un bit de espera de despertar a la escena. Cuando se envía una llamada de 
despertar a un proceso que está despierto, se enciende este bit. Después, cuando el proceso trata de 
dormirse, si el bit de espera de despertar está encendido, se 
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apagará, pero el proceso seguirá despierto. El bit de espera de despertar actúa como una alcancía de 
señales de despertar. Aunque el bit de espera de despertar nos salva el pellejo en este ejemplo, es fácil 
construir ejemplos con tres o más procesos en los que un bit de espera de despertar es insuficiente. 
Podríamos crear otro parche y agregar un segundo bit de espera de despertar, o quizá 8 o 32, pero en 
principio el problema sigue ahí. 


2.2.5 Semáforos 

Ésta era la situación en 1965, cuando E. W. Dijkstra (1965) sugirió usar una variable entera para contar el 
número de señales de despertar guardadas para uso futuro. En esta propuesta se introdujo un nuevo tipo de 
variable, llamada semáforo. Un semáforo podía tener el valor O, indicando que no había señales de 
despertar guardadas, o algún valor positivo si había una o más señales de despertar pendientes. 

Dijkstra propuso tener dos operaciones, DOWN y UP (generalizaciones de SLEEP y WAKEUP, 
respectivamente). La operación DOWN (abajo) aplicada a un semáforo verifica si el valor es mayor que 
O; de ser así, decrementa el valor (esto es, gasta una señal de despertar almacenada) y continúa. Si el valor 
es O, el proceso se pone a dormir sin completar la operación DOWN por el momento. La verificación del 
valor, su modificación y la acción de dormirse, si es necesaria, se realizan como una sola acción atómica 
indivisible. Se garantiza que una vez que una operación de semáforo se ha iniciado, ningún otro proceso 
podrá acceder al semáforo hasta que la operación se haya completado o bloqueado. Esta atomicidad es 
absolutamente indispensable para resolver los problemas de sincronización y evitar condiciones de 
competencia. 

La operación UP incrementa el valor del semáforo direccionado. Si uno o más procesos están 
durmiendo en espera de ese semáforo, imposibilitados de completar una operación DOWN previa, el 
sistema escoge uno de ellos (p. ej., al azar) y le permite completar su DOWN. Así, después de un up con 
un semáforo que tiene procesos durmiendo esperando, el semáforo seguirá siendo O, pero habrá un 
proceso menos que se halle en fase de durmiendo esperando. La operación de incrementar el semáforo y 
despertar un proceso también es indivisible. Ningún proceso se bloquea durante un up, así como ningún 
proceso se bloquea realizando un WAKEUP en el modelo anterior. 

Como acotación, en su artículo original Dijkstra usó las letras P y en lugar de DOWN y UP, 
respectivamente, pero en vista de que éstos no tienen significado mnemónico para quienes no hablan 
holandés (y apenas un significado marginal para quienes lo hablan), usaremos los términos DOWN y up 
en vez de ésos. DOWN y UP se introdujeron por primera vez en Algol 68. 


Resolución del problema de productor-consumidor usando semáforos 

Los semáforos resuelven el problema de la señal de despertar perdida, como se muestra en la Fig. 2-12. Es 
indispensable que se implementen de modo que sean indivisibles. El método normal consiste 
en implementar UF y DOWN como llamadas al sistema, para que el sistema operativo 
inhabilite brevemente todas las interrupciones mientras prueba el semáforo, lo actualiza y pone el 
proceso a dormir, si es necesario. Todas estas acciones requieren sólo unas cuantas instrucciones, 
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así que la inhabilitación de las interrupciones no tiene consecuencias adversas. Si se están usando 
múltiples CPU, cada semáforo debe estar protegido con una variable de candado, usando la instrucción 
TSL para asegurarse de que sólo una CPU a la vez exa mi ne el semáforo. Cerciórese de entender que el 
empleo de TSL para evitar que varias CPU accedan al semáforo al mismo tiempo es muy diferente de la 
espera activa del productor o el consumidor cuando esperan que el otro vacíe o llene el buffer. La 
operación del semáforo sólo toma unos cuantos microsegundos, mi entras que el productor o el consumidor 
podrían tardar un tiempo arbitrariamente largo. 


MefrneN 100 
typedef ínt semaphore; 
semaphore mutex ■ 1; 
semaphore empty = N; 
semaphore full = 0 

void producer(void) 

{ 

int ítem; 

while (TRUE) { 

produce _¡tem(&item); 

down(&empty); 

down(&mutex); 

enterjtem(item); 

up(&mutex); 

up(&full); 

} 

} 

void consumer(void) 

í 

int Item; 

while (TRUE) { 

down(&full); 

down(&mutex); 

removeitem(&¡tem); 

up(&mutex); 

up(&empty). 

consumejtem(item); 

} 

} 


r número de ranuras del buffer 7 
/* los semáforos son un tipo especial de int 7 
r controla el acceso a la región crítica 7 
r cuenta las ranuras de buffer vacías 7 
I* cuenta las ranuras de buffer llenas 7 


/* TRUE es la constante t 7 

/* generar algo para ponerlo en el buffer 7 

/* decrementar el contador empty 7 

r entrar en la región crítica 7 

/* colocar el nuevo elemento en el buffer 7 

r salir de la región crítica 7 

/* incrementar el contador de ranuras llenas 7 


/* ciclo infinito 7 

/* decrementar el contador full 7 

r entrar en la región crítica 7 

/* sacar elemento del buffer 7 

/* salir de la región crítica 7 

/• incrementar el contador de ranuras vacias 7 

/* hacer algo con el elemento 7 


f igura 2-12. El problema de productor-consumidor usando semáforos. 
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Esta solución usa tres semáforos: uno llamado full para contar el número de ranuras que están llenas, 
uno llamado emply para contar el número de ranuras que están vacías, y otro llamado mutex para 
asegurarse de que el productor y el consumidor no accedan al buffer al mismo tiempo. Full inicialmente 
vale O, empty inicialmente es igual al número de ranuras del buffer y mutex inicialmente es 1. Los 
semáforos a los que se asigna 1 como valor inicial y son utilizados por dos o más procesos para asegurar 
que sólo uno de ellos pueda entrar en su región crítica al mismo tiempo se deno mi nan semáforos 
binarios. Si cada proceso ejecuta DOWN justo antes de entrar en su región crítica, y up justo después de 
salir de ella, la exclusión mutua está garantizada. 

Ahora que contamos con una buena primitiva de comunicación entre procesos, regresemos y 
examinemos otra vez la secuencia de interrupción de la Fig. 2-5. En un sistema que usa semáforos, la 
forma natural de ocultar las interrupciones es tener un semáforo, inicialmente puesto en O, asociado a 
cada dispositivo de E/S. Inmediatamente después de iniciar un dispositivo de E/S, el proceso que lo 
administra ejecuta DOWN con el semáforo correspondiente, bloqueándose así de inmediato. Cuando llega 
la interrupción, el manejador de instrucciones ejecuta up con el semáforo correspondiente, haciendo que el 
proceso en cuestión quede otra vez listo para ejecutarse. En este modelo, el paso 6 de la Fig, 2-5 consiste 
en ejecutar UP con el semáforo del dispositivo, de modo que en el paso 7 el planificador pueda ejecutar el 
administrador del dispositivo. Desde luego, si ahora varios procesos están listos, el planificador puede 
optar por ejecutar a continuación un proceso aún más importante. Más adelante en este capítulo veremos 
cómo se realiza la planificación. 

En el ejemplo de la Fig. 2-12, realmente usamos los semáforos de dos formas distintas. Esta 
diferencia es lo bastante importante como para hacerla explícita. El semáforo mutex se usa para exclusión 
mutua; está diseñado para garantizar que sólo un proceso a la vez estará leyendo o escribiendo el buffer y 
las variables asociadas a él. Esta exclusión mutua es necesaria para evitar el caos. 

El otro uso de los semáforos es la sincronización. Los semáforos full y empty se necesitan para 
garantizar que ciertas secuencias de sucesos ocurran o no ocurran. En este caso, los semáforos aseguran 
que el productor dejará de ejecutarse cuando el buffer esté lleno y que el consumidor dejará de ejecutarse 
cuando el buffer esté vacío. Este uso es diferente de la exclusión mutua. 

Aunque los semáforos se han usado desde hace más de un cuarto de siglo, todavía se siguen 
efectuando investigaciones sobre su uso. Por ejemplo, véase (Tai y Carver, 1996). 


2,2.6 Monitores 

Con los semáforos, la comunicación entre procesos parece fácil, ¿no es así? Ni por casualidad. Examine 
de cerca el orden de los DOWN antes de colocar elementos en el buffer o retirarlos de él en la Fig. 2-12. 
Suponga que el orden de los dos DOWN del código del productor se invirtiera, de modo que mutex se 
incrementara antes que empty en lugar de después de él. Si el buffer estuviera completamente lleno, el 
productor se bloquearía, con mutex puesto en O. En consecuencia, la próxima vez que el consumidor 
tratara de acceder al buffer ejecutaría DOWN con mutex, que ahora es O, y también se bloquearía. Ambos 
procesos permanecerían bloqueados indefinidamente y ya no se efectuaría más trabajo. Esta lamentable 
situación se llama bloqueo mutuo, y la estudiaremos con detalle en el capítulo 3. 
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Señalamos este problema para destacar el cuidado que debemos tener al usar semáforos. Basta un 
error sutil para que todo se paralice. Es como programar en lenguaje ensamblador, sólo que peor, porque 
los errores son condiciones de competencia, bloqueo y otras formas de comportamiento impredecible e 
irreproducible. 

A fin de facilitar la escritura de programas correctos, Hoare (1974) y Brinch Hansen (1975) 
propusieron una primitiva de sincronización de nivel más alto llamada monitor. Sus propuestas tenían 
pequeñas diferencias, que describiremos más adelante. Un monitor es una colección de procedimientos, 
variables y estructuras de datos que se agrupan en un tipo especial de módulo o paquete. Los procesos 
pueden invocar los procedimientos de un monitor en el momento en que deseen, pero no pueden acceder 
directamente a las estructuras de datos internas del monitor desde procedimientos declarados afuera del 
monitor. La Fig. 2-13 ilustra un monitor escrito en un lenguaje imaginario parecido a Pascal: 


monitor exampie 
integer i: 
condition r; 

procedure producerix). 


end; 

procedure consumerix ); 


end; 

end monitor: 


Figura 2-13. Un monitor. 


Los monitores poseen una propiedad especial que los hace útiles para lograr la exclusión mutua: 
sólo un proceso puede estar activo en un monitor en un momento dado. Los monitores son una 
construcción de lenguaje de programación, así que el compilador sabe que son especiales y puede manejar 
las llamadas a procedimientos de monitor de una forma diferente a como maneja otras llamadas a 
procedimientos. Por lo regular, cuando un proceso invoca un procedimiento de monitor, las primeras 
instrucciones del procedimiento verifican si hay algún otro proceso activo en ese momento dentro del 
monitor. Si así es, el proceso invocador se suspende hasta que el otro proceso abandona el monitor. Si 
ningún otro proceso está usando el monitor, el proceso invocador puede entrar. 

Es responsabilidad del compilador implementar la exclusión mutua en las entradas a monitores, 
pero una forma común es usar un semáforo binario. Puesto que el compilador, no el programador, 
se está encargando de la exclusión mutua, es mucho menos probable que algo salga mal. En 
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cualquier caso, la persona que escribe el monitor no tiene que saber cómo el compilador logra la exclusión 
mutua; le basta con saber que si convierte todas las regiones críticas en procedimientos de monitor, dos 
procesos nunca podrán ejecutar sus regiones críticas al mismo tiempo. 

Aunque los monitores ofrecen una forma fácil de lograr la exclusión mutua, esto no es suficiente, 
como acabamos de ver. También necesitamos un mecanismo para que los procesos se bloqueen cuando no 
puedan continuar. En el problema de productor-consumidor, es fácil colocar todas las pruebas para 
determinar si el buffer está lleno o está vacío en procedimientos de monitor, pero ¿cómo deberá 
bloquearse el productor cuando encuentra lleno el buffer? 

La solución está en la introducción de variables de condición, junto con dos operaciones que se 
realizan con ellas, WA y SIGNAL. Cuando un procedimiento de monitor descubre que no puede continuar 
(p. ej., si encuentra lleno el buffer), ejecuta WA1T (esperar) con alguna variable de condición, digamos 
full! (lleno). Esta acción hace que el proceso invocador se bloquee, y también permite la entrada de otro 
proceso al que antes se le había impedido entrar en el monitor. 

Este otro proceso (p. ej., el consumidor) puede despertar a su “compañero” dormido ejecutando 
SIGNAL (señal) con la variable de condición que su compañero está esperando. A fin de evitar la 
presencia de dos procesos activos en el monitor al mismo tiempo, necesitamos una regla que nos diga qué 
sucede después de ejecutarse SIGNAL. Hoare propuso dejar que el proceso recién despertado se ejecute, 
suspendiendo el otro. Brinch Hansen propuso sortear el problema exigiendo al proceso que ejecutó 
SIGNAL salir inmediatamente del monitor. Dicho de otro modo, una instrucción SIGNAL sólo puede 
aparecer como última instrucción de un procedimiento de monitor. Usaremos la propuesta de Brinch 
Hansen porque es conceptualmente más sencilla y también más fácil de implementar. Si se ejecuta 
SIGNAL con una variable de condición que varios procesos están esperando, sólo uno de ellos, el que el 
planificador del sistema determine, será reactivado. 

Las variables de condición no son contadores; no acumulan señales para uso futuro como hacen los 
semáforos. Por tanto, si se ejecuta SIGNAL con una variable de condición que ningún proceso está 
esperando, la señal se pierde. La operación WA1T debe venir antes que SIGNAL. Esta regla simplifica 
mucho la implementación. En la práctica, esto no es un problema porque es fácil seguir la pista al estado 
de cada proceso con variables, si es necesario. Un proceso que de otra manera ejecutaría SIGNAL puede 
ver que esta operación no es necesaria si examina las variables. 

En la Lig. 2-14 se presenta un esqueleto del problema productor-consumidor con monitores, escrito 
en seudo-Pascal. 

El lector tal vez esté pensando que las operaciones WA1T y SIGNAL son similares a SLEEP y 
WAKEUP que, como vimos antes, tenían condiciones de competencia fatales. Son muy similares, pero 
tienen una diferencia crucial: SLEEP y WAKEUP fallaron porque mi entras un proceso intentaba 
dormirse, el otro estaba tratando de despertarlo. Con monitores, esto no puede suceder. La exclusión 
mutua automática en los procedimientos de monitor garantiza que si, por ejemplo, el productor dentro de 
un procedimiento de monitor descubre que el buffer T está lleno, podrá completar la operación WA1T sin 
tener que preocuparse por la posibilidad de que el planificador pueda conmutar al consumidor justo antes 
de que se complete el WA1T. El consumidor ni siquiera podrá entrar en el monitor en tanto el WA1T no se 
haya completado y el productor haya dejado de ser ejecutable. 
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Al hacer automática la exclusión mutua de las regiones críticas, los monitores hacen a la 
programación en paralelo mucho menos propensa a errores que cuando se usan semáforos. No obstante, 
tienen algunas desventajas. No es por capricho que la Fig. 2-14 está escrita en un lenguaje ficticio y no en 
C, como otros ejemplos de este libro. Como dijimos antes, los monitores son un concepto de lenguajes de 
programación. El compilador debe reconocerlos y lograr de alguna manera la exclusión mutua. C, Pascal y 
casi todos los demás lenguajes carecen de monitores, por lo que no es razonable esperar que sus 
compiladores hagan cumplir reglas de exclusión mutua. De hecho, ¿cómo podría el compilador saber 
siquiera cuáles procedimientos están en monitores y cuáles no? 

Estos mismos lenguajes tampoco tienen semáforos, pero la adición de semáforos es fácil: todo lo que 
se necesita es agregar dos rutinas cortas escritas en lenguaje ensamblador a la biblioteca para poder emitir 
las llamadas al sistema UP y DOWN. Los compiladores ni siquiera tienen que saber que existen. Desde 
luego, los sistemas operativos tienen que estar enterados de los semáforos, pero al menos si se cuenta con 
un sistema operativo basado en semáforos es posible escribir los programas de usuario para él en C o C++ 
(o incluso BASIC si su masoquismo llega a tanto). En el caso de los monitores, se necesita un lenguaje 
que los tenga incorporados. Unos cuantos lenguajes, como Concurrent Euclid (Holt, 1983) los tienen, pero 
son poco comunes. 

Otro problema con los monitores, y también con los semáforos, es que se diseñaron con la intención 
de resolver el problema de la exclusión mutua en una o más CPU, todas las cuales tienen acceso a una 
memoria común. Al colocar los semáforos en la memoria compartida y protegerlos con instrucciones TSL, 
podemos evitar las competencias. Cuando pasamos a un sistema distribuido que consiste en múltiples 
CPU, cada una con su propia memoria privada, conectadas por una red de área local, estas primitivas ya 
no son aplicables. La conclusión es que los semáforos son de nivel demasiado bajo y que los monitores 
sólo pueden usarse con unos cuantos lenguajes de programación. Además, ninguna de las primitivas 
contempla el intercambio de información entre máquinas. Se necesita otra cosa. 


2,2.7 Transferencia de mensajes 

Esa otra cosa es la transferencia de mensajes. Este método de comunicación entre procesos utiliza dos 
primitivas SEND y RECEIVE que, al igual que los semáforos y a diferencia de los monitores, son 
llamadas al sistema y no construcciones del lenguaje. Como tales, es fácil colocarlas en procedimientos de 
biblioteca, como 

send(destino, &mensaje); 

y 

receive(origen, &mensaje); 


La primera llamada envía un mensaje a un destino dado, y la segunda recibe un mensaje de un 
origen dado (o de cualquiera [ANY] si al receptor no le importa). Sino hay un mensaje disponible, 
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el receptor podría bloquearse hasta que uno llegue. Como alternativa, podría regresar de inmediato con un 
código de error. 


Aspectos de diseño de los sistemas de transferencia de mensajes 


Los sistemas de transferencia de mensajes tienen muchos problemas y aspectos de diseño complicados 
que no se presentan con los semáforos ni con los monitores, sobre todo si los procesos en comunicación 
están en diferentes máquinas conectadas por una red. Por ejemplo, se pueden perder mensajes en la red. 
Para protegerse contra la pérdida de mensajes, el emisor y el receptor pueden convenir que, tan pronto 
como se reciba un mensaje, el receptor enviará de regreso un mensaje especial de acuse de recibo o 
confirmación. Si el emisor no recibe el acuse dentro de cierto intervalo de tiempo, retransmitirá el 
mensaje. 

Consideremos ahora lo que sucede si el mensaje en sí se recibe correctamente, pero se pierde el acuse 
de recibo. El emisor retransmitirá el mensaje, de modo que el receptor lo recibirá dos veces. Es 
indispensable que el receptor pueda distinguir un mensaje nuevo de la retrans mi sión de uno viejo. Por lo 
regular, este problema se resuelve incluyendo números de secuencia consecutivos en cada mensaje 
original. Si el receptor recibe un mensaje que tiene el mismo número de secuencia que uno anterior, sabrá 
que el mensaje es un duplicado y podrá ignorarlo. 

Los sistemas de mensajes también tienen que resolver la cuestión del nombre de los procesos, a fin 
de que el proceso especificado en una llamada SEND o RECEIVE no sea ambiguo. La verificación de 
autenticidad es otro problema en los sistemas de mensajes: ¿cómo puede el cliente saber que se está 
comunicando con el verdadero servidor de archivos, y no con un impostor? 

En el otro extremo del espectro, hay aspectos de diseño que son importantes cuando el emisor y el 
receptor están en la misma máquina. Uno de éstos es el rendimiento. El copiado de mensajes de un 
proceso a otro siempre es más lento que efectuar una operación de semáforo o entrar en un monitor. Se ha 
trabajado mucho tratando de hacer eficiente la transferencia de mensajes. Cheriton (1984), por ejemplo, ha 
sugerido li mi tar el tamaño de los mensajes a lo que cabe en los registros de la máquina, y efectuar luego la 
transferencia de mensajes usando los registros. 


El problema de productor-consumidor con transferencia de mensajes 


Veamos ahora cómo puede resolverse el problema de productor-consumidor usando transferencia de 
mensajes y sin compartir memoria. En la Fig. 2-15 se presenta una solución. Suponemos que todos los 
mensajes tienen el mismo tamaño y que el sistema operativo coloca automáticamente en buffers los 
mensajes enviados pero aún no recibidos. En esta solución se usa un total de N mensajes, análogos a las N 
ranuras de un buffer en memoria compartida. El consu mi dor inicia enviando Nmensajes vacíos al 
productor. Cada vez que el productor tiene un elemento que entregar al consumidor, toma un mensaje 
vacío y devuelve uno lleno. De este modo, el número total de mensajes en el sistema permanece constante 
y pueden almacenarse en una cantidad de memoria que se conoce con antelación. 
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Si el productor trabaja con mayor rapidez que el consumidor, todos los mensajes quedarán llenos, 
esperando al consumidor; el productor se bloqueará, esperando la llegada de un mensaje vacío. Si el 
consu mi dor trabaja con mayor rapidez, ocurre lo opuesto: todos los mensajes estarán vacíos esperando que 
el productor los llene; el consumidor estará bloqueado, esperando un mensaje lleno. 


¿define N 100 

void producer(void) 

{ 

int Item; 

message m; 

while (TRUE) { 

produce Jtem(&item); 
receive(consumer. &m); 
buikJ message(&m, Ítem), 
send(consumer, &m); 

> 

} 

void consume^ void) 

{ 

int ítem, i; 

message m; 

for(i = 0; i < N; i++) send(producer, &m); 

while (TRUE) { 

receive(producer, &m); 
extract Jtem(&m. &item); 
sendíproducer, &m). 
consume_rtem(item); 

} 

) 


/* número de ranuras del buffer V 


/* buffer de mensaje V 


r generar algo que poner en el buffer V 
/* esperar que llegue un mensaje vacío V 
/* construir un mensaje para enviar */ 
r enviar elemento al consumidor V 


/* enviar N mensajes vacíos 7 

r obtener mensaje que contiene elemento 7 
/* extraer elemento del mensaje */ 

T devolver una respuesta vacía */ 

/* hacer algo con el elemento */ 


La transferencia de mensajes puede tener muchas variantes. Para comenzar, veamos cómo se dirigen 
los mensajes. Una forma es asignar a cada proceso una dirección única y hacer que los mensajes se dirijan 
a los procesos. Un método distinto consiste en inventar una nueva estructura de datos, llamada buzón. 
Un buzón es un lugar donde se almacena temporalmente cierta cantidad de mensajes, que 
norma lm ente se especifican cuando se crea el buzón. Si se usan buzones, los 
parámetros de dirección de las llamadas SEND y RECEIVE son buzones, no procesos. Cuando un 
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proceso trata de transmitir a un buzón que está lleno, queda suspendido hasta que se retira un mensaje de 
ese buzón, dejando espacio para uno nuevo. 

En el caso del problema de productor-consumidor, tanto el productor como el consumidor crearían 
buzones con espacio suficiente para N mensajes. El productor enviaría mensajes con datos al buzón del 
consumidor, y éste enviaría mensajes vacíos al buzón del productor. Si se usan buzones, el mecanismo de 
almacenamiento temporal es claro: el buzón de destino contiene mensajes que se han enviado al proceso 
de destino pero todavía no han sido aceptados. 

La otra forma extrema de manejar buzones es eliminar todo el almacenamiento temporal. Cuando se 
adopta este enfoque, si el SEND se ejecuta antes que el RECEIVE, el proceso emisor queda bloqueado 
hasta que ocurre el RECEIVE, y en ese momento el mensaje podrá copiarse directamente del emisor al 
receptor, sin buffers intermedios. De forma similar, si el RECEIVE se ejecuta primero, el receptor se 
bloquea hasta que ocurre el SEND. Esta estrategia se conoce como cita o rendezvous; es más fácil de 
implementar que un esquema de mensajes con almacenamiento temporal, pero es menos flexible, pues se 
obliga al emisor y al receptor a operar estrictamente sincronizados. 

La comunicación entre los procesos de usuario en MINIX (y en UNIX) se efectúa a través de 
conductos, que efectivamente son buzones. La única diferencia real entre un sistema de mensajes con 
buzones y el mecanismo de conductos es que los conductos no preservan los límites de los mensajes. 
Dicho de otro modo, si un proceso escribe 10 mensajes de 100 bytes cada uno en un conducto y otro 
proceso lee 1000 bytes de ese conducto, el lector obtendrá los 10 mensajes a la vez. Con un verdadero 
sistema de mensajes, cada READ debería devolver sólo un mensaje. Desde luego, silos procesos 
convienen en leer y escribir siempre mensajes de tamaño fijo del conducto, o en terminar cada mensaje 
con un carácter especial (p. ej., salto de línea), no habrá problema. Los procesos que constituyen el 
sistema operativo MINIX mismo utilizan un verdadero esquema de mensajes de tamaño fijo para 
comunicarse entre sí. 


2.3 PROBLEMAS CLÁSICOS DE IPC 


La literatura sobre sistemas operativos abunda en problemas interesantes que han sido estudiados y 
analizados ampliamente. En las siguientes secciones examinaremos tres de los más conocidos. 


23.1 El problema de la cena de filósofos 

En 1965, Dijkstra planteó y resolvió un problema de sincronización al que llamó problema de la cena de 
filósofos. Desde entonces, quienquiera que haya inventado una primitiva de sincronización más se ha 
sentido obligado a demostrar lo maravillosa que es mostrando la forma tan elegante en que resuelve el 
problema de la cena de filósofos. El problema tiene un planteamiento muy sencillo. Cinco filósofos están 
sentados alrededor de una mesa circular. Cada filósofo tiene ante sí un plato de espagueti. El espagueti es 
tan resbaloso que un filósofo necesita dos tenedores para comerlo. Entre cada par de platos hay un 
tenedor. La disposición de la mesa se ilustra en la Fig. 2-16. 
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Figura 2-16. Hora de comer en el departamento de filosofía. 


La vida de un filósofo consiste en periodos alternantes de comer y pensar. (Esto es una abstracción, 
incluso en el caso de un filósofo, pero las demás actividades no son pertinentes aquí.) Cuando un filósofo 
siente hambre, trata de adquirir sus tenedores izquierdo y derecho, uno a la vez, en cualquier orden. Si 
logra adquirir dos tenedores, comerá durante un rato, luego pondrá los tenedores en la mesa y seguirá 
pensando. La pregunta clave es: ¿podemos escribir un programa para cada filósofo que haga lo que se 
supone que debe hacer y nunca se entrampe? (Se ha señalado que el requisito de los dos tenedores es un 
tanto artificial; tal vez deberíamos cambiar de la comida italiana a la china, sustituyendo el espagueti por 
arroz y los tenedores por palillos chinos.) 

La Fig. 2-17 muestra la solución obvia. El procedimiento take fork (tomar tenedor) espera hasta 
que el tenedor especificado está disponible y luego se apodera de él. Desafortunadamente, la solución 
obvia está equivocada. Supongamos que todos los filósofos toman su tenedor izquierdo simultáneamente. 
Ninguno podrá tomar su tenedor derecho, y tendremos un bloqueo mutuo. 

Podríamos modificar el programa de modo que, después de tomar el tenedor izquierdo, el programa 
verifique si el tenedor derecho está disponible. Si no es así, el filósofo soltará su tenedor izquierdo, 
esperará cierto tiempo, y repetirá el proceso. Esta propuesta también fracasa, aunque por una razón 
distinta. Con un poco de mala suerte, todos los filósofos podrían iniciar el algoritmo simultáneamente, 
tomar su tenedor izquierdo, ver que su tenedor derecho no está disponible, dejar su tenedor izquierdo, 
esperar, tomar su tenedor izquierdo otra vez de manera simultánea, y así eternamente. Una situación así, 
en la que todos los programas continúan ejecutándose de manera indefinida pero no logran avanzar se 
deno mi na inanición (adopta este calificativo aun cuando el problema no ocurra en un restaurante italiano 
o chino). 

Ahora podríamos pensar: “si los filósofos esperan un tiempo aleatorio en lugar del 
mismo tiempo después de fracasar en su intento por .disponer del tenedor derecho, la posibilidad de que 
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¿define N 5 


r número de filósofos 7 


void philosopher(int i) 

{ 

while (TRUE) { 


r i: número de filósofo, de 0 a 4 7 


think(); 


/* el filósofo está pensando 7 
r tomar tenedor izquierdo 7 

/* tomar tenedor derecho; % es el operador de residuo 7 
/* delicioso espagueti 7 

/* poner el tenedor Izquierdo otra vez en la mesa 7 
/* poner el tenedor derecho otra vez en la mesa 7 


takejork(i); 


takeJori<((i+1) % N); 
eat(); 


putjork(i); 


put_fork((k1) % N); 


> 


} 


Figura 2-17. Una no-solución al problema de la cena de filósofos. 


sus acciones continuaran coordinadas durante siquiera una hora es excesivamente pequeña”. Esto es 
cierto, pero en algunas aplicaciones preferiríamos una solución que siempre funcione y que no tenga 
posibilidad de fallar debido a una serie improbable de números aleatorios. (Pensemos en el control de 
seguridad en una planta de energía nuclear.) 

Una mejora de la Fig. 2-17 que no está sujeta a bloqueo ni inanición consiste en proteger las cinco 
instrucciones que siguen a la llamada a think (pensar) con un semáforo binario. Antes de comenzar a 
conseguir tenedores, un filósofo ejecutaría DOWN con mutex. Después de dejar los tenedores en la mesa, 
ejecutaría up con mutex. Desde un punto de vista teórico, esta solución es adecuada. En la práctica, 
empero, tiene un problema de rendimiento: sólo un filósofo puede estar comiendo en un ins tante dado. Si 
hay cinco tenedores disponibles, deberíamos estar en condiciones de permitir que dos filósofos co mi eran 
al mismo tiempo. 

La solución que se presenta en la Fig. 2-18 es correcta y también admite un paralelismo máximo con 
un número arbitrario de filósofos. Se utiliza un arreglo State (estado) para mantenerse al tanto de si un 
filósofo está comiendo, pensando o hambriento (tratando de disponer de tenedores). Un filósofo sólo 
puede pasar a la situación de “comiendo” si ninguno de sus vecinos está comiendo. Los vecinos del 
filósofo i están definidos por las macros LEFT y RIGHT. En otras palabras, si i es 2, LEFT es 1 y RIGHT 
es 3. 

El programa utiliza un arreglo de semáforos, uno por filósofo, de modo que los filósofos 
hambrientos pueden bloquearse silos tenedores que necesitan están ocupados. Observe que cada proceso 
ejecuta el procedimiento philosopher (filósofo) como código principal, pero los demás procedimientos, 
take forks (tomar tenedores), put forks (poner tenedores) y test (probar) son procedimientos ordinarios y 
no procesos aparte. 


23.2 El problema de lectores y escritores 

El problema de la cena de filósofos es útil para modelar procesos que compiten por tener 
acceso exclusivo a un número limitado de recursos, como dispositivos de E/S. Otro problema famoso es 
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U dafne N 5 

■MelinelEFT (H)%N 
tf define RIGHT <1+1 )«N 

M«fina THINKIMG 0 

tfdefma HÜHGflV t 

¿define EATING 2 

y número da' filosofas 7 
/* número del vecino izquierdo de 17 
i* número del vecino derecho de i 7 
f el filósofo ealá pensando m i 
r el fltósolo ¡menta obienaí tenedoras V 
r el filósofo ealá CO rotando 7 

lypedcí int seThaphoi'e; 
inl &1¿ie|N|, 
semaphurg mulB* = 1 ; 

semaphore s|M], 
void philosopheríin! i) 

{ 
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ihlrtcO: 

Ml(); 

puUwtaffl: 

T los semáforos son un tipo especial de -inl 7 
r enrollo pare seflwr fe piala al oslado de lodos 7 

T exclusión mutua pera r^iOnos orificas 7 

P un semáforo por filósofo 7 
r i: número de misero.. de o a N-i 7 

f* repitir indefinidamente V 

f @i blósofo está pensando 7 
/" adquirir dos tenedoras o bloquearse 7 
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r dejar ambos tenedores en la masa 7 

) 

} 
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{ 
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y entrar en la región critica 7 
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r ver si el veono ¡zquKKdo añoro puede comer 7 
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el de los lectores y escritores (Courtois et al., 1971), que modela el acceso a una base de datos. 
Imaginemos, por ejemplo, un sistema de reservaciones de una línea aérea, con muchos procesos 
competidores que desean leerlo y escribir en él. Es aceptable tener múltiples procesos leyendo la base de 
datos al mismo tiempo, pero si un proceso está actualizando (escribiendo en) la base de datos, ningún otro 
podrá tener acceso a ella, ni siquiera los lectores. La pregunta es, ¿cómo pro gramamos a los lectores y 
escritores? Una solución se muestra en la Fig. 2-19. 


typedef int semaphore; 
semaphore mutex = 1; 
semaphore db = 1; 
int re = 0; 


/* use su imaginación 7 
r controla el acceso a ’rc’ 7 
/* controla el acceso a la base de datos 7 
/* núm. de procesos que leen o quieren leer 7 


void reader(void) 

{ 

while (TRUE) { 

down(4mutex), 
rc = rc+ 1; 

if (re = 1) down(&db): 

up(&mutex); 

read_data_base(); 

down(Amutex); 

rc = rc-1; 

if (re = 0) upí&db); 

up(&mutex); 

use_data_read(); 

) 

> 


/* repetir indefinidamente 7 
r obtener acceso exclusivo a ’rc’ V 
/* ahora un lector más 7 
/* si éste es el primer lector... 7 
r liberar el acceso exclusivo a ’rc’ 7 
/* acceder a los datos 7 
r obtener acceso exclusivo a 're' 7 
r ahora un lector menos 7 
/* si éste es el último lector... 7 
/* liberar el acceso exclusivo a ’rc’ 7 
r región no crítica 7 


void writer(void) 

{ 

while (TRUE) { 

think_up_data(); 

down(4db); 

write_data_base{); 

up(4db). 

} 

} 


r repetir indefinidamente 7 
r región no crítica 7 
t' obtener acceso exclusivo 7 
/* actualizar los datos 7 
r liberar el acceso exclusivo 7 


Figura 2-19. Una solución al problema de lectores y escritores. 


En esta solución, el primer lector que obtiene acceso a la base de datos ejecuta DOWN con el 
semáforo db. Los lectores subsecuentes se limitan a incrementar un contador, re. Conforme los lectores 
salen, decrementan el contador, y el último en salir ejecuta UP con el semáforo para permitir que un 
escritor bloqueado, silo había, entre. 
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La solución que presentamos aquí contiene implícitamente una sutil decisión que vale la pena 
comentar. Supongamos que mientras un lector está usando la base de datos, llega otro lector. Puesto que 
tener dos lectores al mismo tiempo no está prohibido, se admite al segundo lector. También pueden 
admitirse un tercer lector y lectores subsecuentes si llegan. 

Supongamos ahora que llega un escritor. El escritor no puede ser admitido en la base de datos, 
pues requiere acceso exclusivo, de modo que el escritor queda suspendido. Más adelante, llegan lectores 
adicionales. En tanto haya al menos un lector activo, se admitirán lectores subsecuentes. A consecuencia 
de esta estrategia, en tanto haya un suministro constante de lectores, entrarán tan pronto como lleguen. El 
escritor se mantendrá suspendido hasta que no haya ningún lector presente. Si llega un lector, digamos, 
cada 2 segundos, y cada lector tarda 5 segundos en efectuar su trabajo, el escritor nunca entrará. 

Para evitar esta situación, el programa podría incluir una pequeña modificación: cuando llega un 
lector y un escritor está esperando, el lector queda suspendido detrás del escritor en lugar de ser admitido 
inmediatamente. Así, un escritor tiene que esperar hasta que terminan los lectores que estaban activos 
cuando llegó, pero no a que terminen los lectores que llegaron después de él. La desventaja de esta 
solución es que logra menor concurrencia y por tanto un menor rendimiento. Courtois et al., presentan una 
solución que confiere prioridad a los escritores. Si desea conocer los detalles, remítase a su artículo. 


2,3.3 El problema del peluquero dormido 

Otro problema de IPC clásico ocurre en una peluquería. Esta peluquería tiene un peluquero, una silla de 
peluquero y n sillas donde pueden sentarse los clientes que esperan, silos hay. Si no hay clientes presentes, 
el peluquero se sienta en la silla de peluquero y se duerme, como se ilustra en la Fig. 2-20. Cuando llega 
un cliente, tiene que despertar al peluquero dormido. Si llegan clientes adicionales mientras el peluquero 
está cortándole el pelo a un cliente, se sientan (si hay sillas vacías) o bien salen del establecimiento (si 
todas las sillas están ocupadas). El problema consiste en programar al peluquero y sus clientes sin entrar 
en condiciones de competencia. 

Nuestra solución utiliza tres semáforos: customers, que cuenta a los clientes en espera (excluyendo 
al que está siendo atendido, que no está esperando), barbers, el número de peluqueros que están ociosos, 
esperando clientes (0 o 1), y mutex, que se usa para la exclusión mutua. También necesitamos una 
variable, waiting (esperando), que también cuenta los clientes que están esperando, y que en esencia es 
una copia de customers. Necesitamos esta variable porque no es posible leer el valor actual de un 
semáforo. En esta solución, un cliente que entra en la peluquería debe contar el número de clientes que 
esperan. Si este número es menor que el número de sillas, se queda; si no, se va. 

Nuestra solución se muestra en la Fig. 2-21. Cuando el peluquero llega a trabajar en la mañana, 
ejecuta el procedimiento barber (peluquero) que lo obliga a bloquearse en espera de customers hasta que 
llegue alguien. Luego se duerme como se muestra en la Fig. 2-20. 

Cuando un cliente llega, ejecuta customer (cliente), cuya primera instrucción es adquirir mutex para 
entrar en una región crítica. Si otro cliente llega poco tiempo después, no podrá hacer 
nada hasta que el primero haya liberado mutex. A continuación, el cliente verifica si el número de 
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Figura 2-20. El peluquero dormido. 


clientes en espera es menor que el número de sillas. Si no es así, el cliente libera mutex y se sale sin su 
corte de pelo. 

Si hay una silla disponible, el cliente incrementa la variable entera waiting y luego ejecuta UP con el 
semáforo customers, lo que despierta al peluquero. En este punto, tanto el peluquero como el cliente están 
despiertos. Cuando el cliente libera mutex, el peluquero lo toma, realiza algo de aseo e inicia el corte de 
pelo. 

Una vez terminado el corte de pelo, el cliente sale del procedimiento y de la peluquería. A diferencia 
de los ejemplos anteriores, no hay un ciclo para el cliente porque cada uno sólo recibe un corte de pelo. El 
peluquero sí opera en un ciclo, tratando de atender al siguiente cliente. Si hay uno presente, el peluquero 
realiza otro corte de pelo; si no, se duerme. 

Como acotación, vale la pena señalar que si bien los problemas de lectores y escritores y del 
peluquero dormido no implican transferencia de datos, pertenecen al área de IPC porque implican 
sincronización entre varios procesos. 
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#define CHAIRS 5 

typcdcf int semaphorc; 

semaphore customers = 0; 
semaphore barbers = 0; 
semaphore mutex = 1; 
int waiting = 0: 

void barber(void) 

{ 

while (TRUE) { 

down(customers); 
down(mutex); 
waiting = waiting • 1; 
up< barbers); 
up( mutex); 
cut_hair(); 

} 

) 


r núm. sillas para clientes que esperan 7 
/• use su imaginación 7 

r núm. de clientes que esperan ser atendidos 7 
r núm. de peluqueros que esperan clientes 7 
/* para exclusión mutua 7 

r clientes que esperan (no están siendo atendidos) 7 


/* dormirse si el núm. de clientes es 0 7 
r adquirir acceso a 'waiting' 7 
/' decrementar cuenta de clientes en espera 7 
r un peluquero está listo para cortar el pelo 7 
/* liberar waiting' 7 

/* cortar el pelo (fuera de la región critica) 7 


void customer(void) 

{ 

down(mutex); 
if(waiting < CHAIRS) { 

waiting = waiting + 1; 

up(customers); 

up(mutex); 

dowrKbarbers), 

get_haircut(); 

) else { 

up< mutex); 

} 


/* entrar en la región critica 7 

/* si no hay sillas desocupadas, irse 7 

/* incrementar cuenta de clientes en espera 7 

/* despertar al peluquero si es necesario 7 

/* liberar el acceso a 'waiting' 7 

r dormirse si el núm. de peluqueros libres es 0 7 

/* sentarse y ser atendido 7 

/* peluquería llena; no esperar 7 


} 


Figura 2-21. Una solución al problema del peluquero dormido. 


2.4 PLANIFICACIÓN DE PROCESOS 

En los ejemplos de las secciones anteriores tuvimos varias situaciones en las que dos o más procesos (p. 
ej., productor y consumidor) podían ejecutarse lógicamente. Cuando hay más de un proceso ejecutable, el 
sistema operativo debe decidir cuál ejecutará primero. La parte del sistema operativo que toma esta 
decisión se denomina planificador; el algoritmo que usa se denomina algoritmo de planificación. 
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En la época de los sistemas por lote con entradas en forma de imágenes de taijetas en una cinta 
magnética, el algoritmo de planificación era sencillo: simplemente se ejecutaba el siguiente trabajo de la 
cinta. En los sistemas de tiempo compartido, el algoritmo de planificación es más complejo, pues es 
común que haya varios usuarios en espera de ser atendidos, y también puede haber uno o más flujos por 
lotes (p. ej., en una compañía de seguros, para procesar reclamaciones). Incluso en las computadoras 
personales, puede haber varios procesos iniciados por el usuario compitiendo por la CPU, sin mencionar 
los trabajos de segundo plano, como los demonios de red o de correo electrónico que envían o reciben 
mensajes. 

Antes de examinar algoritmos de planificación específicos, debemos pensar en qué está tratando de 
lograr el planificador. Después de todo, éste se ocupa de decidir una política, no de proveer un 
mecanismo. Se nos ocurren varios criterios para determinar en qué consiste un buen algoritmo de 
planificación. Entre las posibilidades están: 


1. Equitatividad —asegurarse de que cada proceso reciba una parte justa del tiempo de CPU. 

2. Eficiencia —mantener la CPU ocupada todo el tiempo. 

3. Tiempo de respuesta —minimizar el tiempo de respuesta para usuarios interactivos. 

4. Retomo —minimizar el tiempo que los usuarios por lotes tienen que esperar sus salidas. 

5. Volumen de producción —maxi miz ar el número de trabajos procesados por hora. 


Si pensamos un poco veremos que algunos de estos objetivos son contradictorios. Si queremos minimizar 
el tiempo de respuesta para los usuarios interactivos, el planificador no deberá ejecutar trabajos por lotes 
(excepto quizá entre las 3 A.M. y las 6 A.M., cuando todos los usuarios interactivos están muy a gusto en 
sus camas). A los usuarios por lotes seguramente no les gustaría este algoritmo, pues viola el criterio 4. 
Puede demostrarse (Kleinrock, 1975) que cualquier algoritmo de planificación que dé preferencia a una 
clase de trabajos perjudicará a los de otras clases. Después de todo, la cantidad de tiempo de CPU 
disponible es finita. Para darle más a un usuario tenemos que darle menos a otro. Así es la vida. 

Una complicación que deben enfrentar los planificadores es que cada proceso es único e 
impredecible. Algunos dedican una buena parte del tiempo a esperar E/S de archivos, mientras otros 
usarían la CPU durante horas si se les permitiera hacerlo. Cuando el planificador comienza a ejecutar un 
proceso, nunca sabe con certeza cuánto tiempo pasará antes de que dicho proceso se bloquee, sea para 
E/S, en espera de un semáforo o por alguna otra razón. Para asegurarse de que ningún proceso se ejecute 
durante demasiado tiempo, casi todas las computadoras tienen incorporado un cronómetro o reloj 
electrónico que genera interrupciones periódicamente. Es común que la frecuencia sea de 50060 
interrupciones por segundo (equivalente a 50 o 60 hertz, abrevia do Hz), pero en muchas computadoras el 
sistema operativo puede ajustar la frecuencia del cronómetro al valor que desee. En cada interrupción de 
reloj, el sistema operativo se ejecuta y decide si debe permitirse que el proceso que se está ejecutando 
actualmente continúe o si ya disfrutó de suficiente tiempo de CPU por el momento y debe suspenderse 
para otorgar a otro proceso la CPU. 
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La estrategia de permitir que procesos lógicamente ejecutables se suspendan temporalmente se 
denomina planificación expropiativa y contrasta con el método de ejecución hasta terminar de los 
primeros sistemas por lotes. La ejecución hasta ter mi nar también se deno mi na planificación no 
expropiativa. Como hemos visto a lo largo del capítulo, un proceso puede ser suspendido en un instante 
arbitrario, sin advertencia, para que otro proceso pueda ejecutarse. Esto da pie a condiciones de 
competencia y requiere semáforos, monitores, mensajes o algún otro método avanzado para prevenirlas. 
Por otro lado, una política de dejar que los procesos se ejecuten durante el tiempo que quieran implicaría 
que un proceso que está calculando it con una precisión de mil millones de cifras podría privar de servicio 
a todos los demás procesos indefinidamente. 

Así, aunque los algoritmos de planificación no apropiativos son sencillos y fáciles de implementar, 
por lo regular no son apropiados para sistemas de aplicación general con varios usuarios que compiten 
entre sí. Por otro lado, en un sistema dedicado como un servidor de base de datos, bien puede ser 
razonable que el proceso padre inicie un proceso hijo para trabajar con una solicitud y dejarlo que se 
ejecute hasta terminar o bloquearse. La diferencia respecto al sistema de aplicación general es que todos 
los procesos del sistema de bases de datos están bajo el control de un solo amo, que sabe lo que cada hijo 
va a hacer y cuánto va a tardar. 


2,4,1 Planificación round robín (de torneo) 

Examinemos ahora algunos algoritmos de planificación específicos. Uno de los más antiguos, sencillos, 
equitativos y ampliamente utilizados es el de round robín. A cada proceso se le asigna un intervalo de 
tiempo, llamado cuanto, durante el cual se le permite ejecutarse. Si el proceso todavía se está ejecutando 
al expirar su cuanto, el sistema operativo se apropia de la CPU y se la da a otro proceso. Si el proceso se 
bloquea o termina antes de expirar el cuanto, la conmutación de CPU naturalmente se efectúa cuando el 
proceso se bloquee. El round robín es fácil de implementar. Todo lo que el planificador tiene que hacer es 
mantener una lista de procesos ejecutables, como se muestra en la Fig. 2-22(a). Cuando un proceso gasta 
su cuanto, se le coloca al final de la lista, como se aprecia en la Fig. 2-22(b). 


Proceso Siguiente 

actual proceso 

(a) 


Proceso 

actual 

ÉD-0—EHIH3 

<b) 


Figura 2-22. Planificación round robín, (a) La lista de procesos ejecutables, (b) La lista 
de procesos ejecutables después de que B gasta su cuanto. 


La única cuestión interesante cuando se usa el round robín es la duración del cuanto. La 
conmutación de un proceso a otro requiere cierto tiempo para llevar a cabo las tareas administrativas: 
guardar y cargar registros y mapas de memoria, actualizar diversas tablas y listas, etc. Su 
pongamos que esta conmutación de proceso o conmutación de contexto requiere 5 ms. 
Supongamos también que usamos cuantos de 20 ms. Con estos parámetros, después de realizar trabajo 
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útil durante 20 ms, la CPU tendrá que ocupar 5 ms en la conmutación de procesos. Se desperdiciará el 
20% del tiempo de CPU en gastos extra administrativos. 

A fin de mejorar la eficiencia de la CPU, podríamos usar cuantos de, digamos, 500 ms. Ahora el 
tiempo desperdiciado es de menos del 1%, pero consideremos lo que sucede en un sistema de tiempo 
compartido silO usuarios interactivos pulsan la tecla de retomo de carro aproximadamente al mismo 
tiempo: diez procesos se pondrían en la lista de procesos ejecutables. Si la CPU está ociosa, el primero se 
iniciará de inmediato, el segundo podría no iniciarse hasta cerca de medio segundo después, y así 
sucesivamente. El pobre proceso que le haya tocado ser último podría tener que esperar 5 segundos antes 
de tener su oportunidad, suponiendo que los demás procesos utilizan su cuanto completo. Para casi 
cualquier usuario, un retardo de 5 segundos en la respuesta a un comando corto sería terrible. El mismo 
problema puede presentarse en una computadora personal que maneja multiprogramación. 

La conclusión puede formularse así: escoger un cuanto demasiado corto causa demasiadas 
Conmutaciones de procesos y reduce la eficiencia de la CPU, pero escogerlo demasiado largo puede dar 
pie a una respuesta deficiente a solicitudes interactivas cortas. Un cuanto de cerca de 100 ms suele ser un 
término medio razonable. 


2.4.2 Planificación por prioridad 

La planificación en round robín supone implícitamente que todos los procesos son igualmente 
importantes. Con frecuencia, las personas que poseen y operan sistemas de computadora multiusuario 
tienen ideas diferentes acerca del tema. En una universidad, la jerarquía puede consistir en decanos 
primero, luego profesores, secretarias, conserjes y, por último, estudiantes. La necesidad de tener en 
cuenta factores externos da pie a la planificación por prioridad. La idea básica es sencilla: a cada 
proceso se le asigna una prioridad, y se permite que se ejecute el proceso ejecutable que tenga la prioridad 
más alta. 

Incluso en una PC con un solo dueño, puede haber múltiples procesos, algunos más importantes que 
otros. Por ejemplo, un proceso demonio que envía correo electrónico en segundo plano debe tener menor 
prioridad que un proceso que está exhibiendo video en tiempo real en la pantalla. 

A fin de evitar que los procesos de alta prioridad se ejecuten indefinidamente, el planificador puede 
reducir la prioridad de los procesos que actualmente se ejecutan en cada tic del reloj (esto es, en cada 
interrupción de reloj). Si esta acción hace que la prioridad se vuelva menor que la del siguiente proceso 
con más alta prioridad, ocurrirá una conmutación de procesos. Como alternativa, se podría asignar a cada 
proceso un cuanto máximo en el que se le permitiera tener la CPU continuamente; cuando se agota este 
cuanto, se da oportunidad al proceso con la siguiente prioridad más alta de ejecutarse. 

Podemos asignar prioridades a los procesos estática o dinámicamente. En una computadora militar, 
los procesos iniciados por generales podrían comenzar con prioridad 100, los iniciados por coroneles 
con 90, por mayores con 80, por capitanes con 70, por tenientes con 60, etc. Como alternativa, 
en un centro de cómputo comercial, los procesos de alta prioridad podrían costar 100 
dólares por hora, los de mediana prioridad 75 dólares por hora, y los de baja prioridad 50 dólares 
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por hora. El sistema UNIX tiene un comando, fice, que permite a un usuario reducir voluntaria mente la 
prioridad de su proceso, con objeto de ser amable con los demás usuarios. Nadie lo usa. 

El sistema también puede asignar prioridades dinámicamente a fin de lograr ciertos objetivos del 
sistema. Por ejemplo, algunos procesos están limitados principalmente por E/S y pasan la mayor parte del 
tiempo esperando que terminen operaciones de BIS. Siempre que un proceso necesita la CPU, se le deberá 
otorgar de inmediato, con objeto de que pueda iniciar su siguiente solicitud de E/S, que entonces podrá 
proceder en paralelo con otro proceso que sí está realizando cálculos. Si hiciéramos que los procesos 
limitados por BIS esperaran mucho tiempo la CPU, implicaría tenerlo por ahí ocupando memoria durante 
un tiempo innecesariamente largo. Un algoritmo sencillo para dar buen servicio a los procesos limitados 
por E/S es asignarles la prioridad 1/f, donde f es la fracción del último cuanto que un proceso utilizó. Un 
proceso que usó sólo 2 ms de su cuanto de 100 ms recibiría una prioridad de 50, en tanto que un proceso 
que se ejecutó 50 ms antes de bloquearse obtendría una prioridad de 2, y uno que ocupó todo su cuanto 
obtendría una prioridad de 1. 

En muchos casos es conveniente agrupar los procesos en clases de prioridad y usar planificación por 
prioridad entre las clases pero planificación round robín dentro de cada clase. La Fig. 2-23 muestra un 
sistema con cuatro clases de prioridad. El algoritmo de planificación es el siguiente: en tanto haya 
procesos ejecutables en la clase de prioridad 4, se ejecutará cada uno durante un cuanto, con round robín, 
sin ocuparse de las clases de menor prioridad. Si la clase de prioridad 4 está vacía, se ejecutan los procesos 
de la clase 3 con round robín. Si tanto la clase 4 como la 3 están vacías, se ejecutan los procesos de clase 2 
con round robín, etc. Si las prioridades no se ajustan ocasionalmente, las clases de baja prioridad podrían 
morir de inanición. 


Cabeceras 
de cola 


Procesos ejecutables 


-o-a-a 

"HZ1-D-C3-D 


(Más alta prioridad) 


(Más baja prioridad) 


Figura 2-23. Algoritmo de planificación con cuatro clases de prioridad. 


2.4.3 Colas múltiples 

Uno de los primeros planificadores por prioridad se incluyó en CTSS (Corbato et al., 1962). CTSS tenía el 
problema de que la conmutación de procesos era muy lenta porque la 7094 sólo podía contener un proceso 
en la memoria. Cada conmutación implicaba escribir el proceso actual en disco y leer uno nuevo del disco. 
Los diseñadores de CTSS pronto se dieron cuenta de que resultaba más eficiente dar a los procesos 
limitados por CPU un cuanto largo de vez en cuando, 
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en lugar de darles cuantos pequeños muy a menudo (porque se reducía el intercambio). Por otro lado, dar 
a todos los procesos un cuanto largo implicaría un tiempo de respuesta deficiente, como ya hemos visto. 
Su solución consistió en establecer clases de prioridad. Los procesos de la clase más alta se ejecutaban 
durante un cuanto. Los procesos de la siguiente clase más alta se ejecutaban durante dos cuantos. Los 
procesos de la siguiente clase se ejecutaban durante cuatro cuantos, y así sucesivamente. Cada vez que un 
proceso agotaba todos los cuantos que tenía asignados, se le degradaba una clase. 

Por ejemplo, consideremos un proceso que necesita calcular continuamente durante 100 cuantos; 
inicialmente, se le daría un cuanto, y luego se intercambiaría por otro proceso. La siguiente vez, recibiría 
dos cuantos antes de ser intercambiado. En ocasiones subsecuentes obtendría 4, 8, 16, 32 y 64 cuantos, 
aunque sólo usaría 37 de los últimos 64 cuantos para completar su trabajo. Sólo se necesitarían 7 
intercambios (incluida la carga inicial) en lugar de 100 si se usara un algoritmo round robín puro. Además, 
al hundirse el proceso progresivamente en las colas de prioridad, se le ejecutaría cada vez con menor 
frecuencia, guardando la CPU para procesos interactivos cortos. 

Se adoptó la siguiente política para evitar que un proceso que en el momento de iniciarse necesita 
ejecutarse durante un tiempo largo pero posteriormente se vuelve interactivo fuera castigado 
indefinidamente. Cada vez que en una terminal se pulsaba el retomo de carro, el proceso perteneciente a 
esa ter mi nal se pasaba a la clase de más alta prioridad, bajo el supuesto de que estaba a punto de volverse 
interactivo. Un buen día un usuario con un proceso muy limitado por CPU descubrió que si se sentaba 
ante su terminal y pulsaba el retomo de carro al azar cada varios segundos su tiempo de respuesta 
mejoraba notablemente. Este usuario se lo dijo a todos sus amigos. Moraleja de la historia: acertar en la 
práctica es mucho más difícil que acertar en la teoría. 

Se han utilizado muchos otros algoritmos para asignar procesos a clases de prioridad. Por ejemplo, el 
influyente sistema XDS 940 (Lampson, 1968), construido en Berkeley, tenía cuatro clases de prioridad, 
llamadas terminal, E/S, cuanto corto y cuanto largo. Cuando un proceso que estaba esperando entradas de 
la terminal finalmente se despertaba, pasaba a la clase de prioridad más alta (terminal). Cuando un proceso 
que estaba esperando un bloque de disco quedaba listo, pasaba a la segunda clase. Si un proceso seguía en 
ejecución en el momento de expirar su cuanto, se le colocaba i ni cialmente en la tercera clase, pero si 
agotaba su cuanto demasiadas veces seguidas sin bloquearse para E/S de ter mi nal o de otro tipo, se le 
bajaba a la cuarta cola. Muchos otros sistemas usan algo similar para dar preferencia a los usuarios y 
procesos interactivos por encima de los de segundo plano. 


2.4,4 El primer trabajo más corto 

La mayor parte de los algoritmos anteriores se diseñaron para sistemas interactivos. Examinemos 
ahora uno que resulta especialmente apropiado para los trabajos por lotes cuyos tiempos de 
ejecución se conocen por adelantado. En una compañía de seguros, por ejemplo, es posible predecir 
con gran exactitud cuánto tiempo tomará ejecutar un lote de 1000 reclamaciones, pues se 
efectúan trabajos similares todos los días. Si hay varios trabajos de igual importancia esperando en la cola 
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de entrada para ser iniciados, el planificador deberá usar el criterio del primer trabajo más corto. 
Examinemos la Fig. 2-24. Aquí encontramos cuatro trabajos, A, B, C y D, con tiempos de ejecución de 8, 
4, 4 y 4 minutos, respectivamente. Si los ejecutamos en ese orden, el tiempo de retomo para A será de 8 
minutos, para B, de 12 minutos, para C, de 16 minutos, y para D, de 20 minutos, siendo el promedio de 14 
minutos. 



4 4 4 8 

B C D A 


<t» 


Figura 2*24. Ejemplo de planificación del primer trabajo más cono. 


Consideremos ahora la ejecución de estos trabajos usando el primer trabajo más corto, como se 
muestra en la Fig. 2-24(b). Los tiempos de retomo son ahora de 4, 8, 12 y 20 mi nutos para un promedio de 
11 minutos. Se puede demostrar que la política del primer trabajo más corto es óptima. Consideremos el 
caso de cuatro trabajos, con tiempos de ejecución de a, b, c y d, respectivamente. El primer trabajo ter mi na 
en un tiempo a, el segundo, en a + b, etc. El tiempo de retomo medio es (4a + 3b + 2c + d)/4. Es evidente 
que a contribuye más al promedio que los demás tiempos, por lo que debe ser el trabajo más corto, 
siguiendo b, c y por último d, que es el más largo y sólo afecta su propio tiempo de retomo. El mismo 
argumento es aplicable a cualquier cantidad de trabajos. 

Dado que la política del primer trabajo más corto produce el tiempo de respuesta medio mínimo, 
sería deseable poderlo usar también para procesos interactivos. Esto es posible hasta cierto punto. Los 
procesos interactivos generalmente siguen el patrón de esperar un comando, ejecutar el comando, esperar 
un comando, ejecutar el comando, etc. Si consideramos la ejecución de cada comando como un “trabajo” 
individual, podremos minimizar el tiempo de respuesta global ejecutando primero el trabajo más corto. El 
único problema es determinar cuál de los procesos ejecutables es el más corto. 

Una estrategia consiste en hacer estimaciones basadas en el comportamiento histórico y ejecutar el 
proceso con el tiempo de ejecución estimado más corto. Supongamos que el tiempo por comando 
estimado para cierta terminal es T 0 Supongamos ahora que se mide su siguiente ejecución, dando Ti 
Podríamos actualizar nuestro estimado calculando una suma ponderada de estos dos números, es decir, aT 0 
+ (1 - a)T! Dependiendo del valor que escojamos para a, podremos hacer que el proceso de estimación 
olvide las ejecuciones viejas rápidamente, o las recuerde durante mucho tiempo. Con a = 1/2, obtenemos 
estimaciones sucesivas de 

T 0 , T 0 /2 + T t /2, T 0 /4 + Tj /4 + T 2 /2, T 0 /8 + T! /8 + T 2 /4 + T 3 12 


Después de tres nuevas ejecuciones, el peso de T 0 en el nuevo estimado se ha reducido a 1/8. 

La técnica de estimar el siguiente valor de una serie calculando la media ponderada del valor medido 
actual y el estimado previo también se conoce como maduración, y es aplicable a muchas 
situaciones en las que debe hacerse una predicción basada en valores previos. La maduración es 
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especialmente fácil de implementar cuando a = 1/2. Todo lo que se necesita es sumar el nuevo valor al 
estimado actual y dividir la suma entre 2 (desplazándola a la derecha un bit). 

Vale la pena señalar que el algoritmo del primer trabajo más corto sólo es óptimo cuando todos los 
trabajos están disponibles simultáneamente. Como contraejemplo, consideremos cinco trabajos, A a E, 
con tiempos de ejecución de 2, 4, 1, 1 y 1, respectivamente. Sus tiempos de llegada son 0, 0, 3, 3 y 3. 

Inicialmente, sólo pueden escogerse A o B, puesto que los otros tres trabajos todavía no llegan. Si 
ejecutamos el primer trabajo más corto, seguiremos el orden de ejecución A, B, C, D, E logrando una 
espera media de 4.6. Sin embargo, silos ejecutamos en el orden B, C, D, E y A la espera media será de 4.4. 


2.4.5 Planificación garantizada 

Una estrategia de planificación totalmente distinta consiste en hacer promesas reales al usuario en cuanto 
al rendimiento y después cumplirlas. Una promesa que es realista y fácil de cumplir es la siguiente: si hay 
n usuarios en sesión mientras usted está trabajando, usted recibirá aproximadamente lln de la capacidad de 
la CPU. De forma similar, en un sistema monousuario con n procesos en ejecución, si todo lo demás es 
igual, cada uno deberá recibir un de los ciclos de CPU. 

Para poder cumplir esta promesa, el sistema debe llevar la cuenta de cuánto tiempo de CPU ha 
tenido cada proceso desde su creación. A continuación, el sistema calculará el tiempo de CPU al que tenía 
derecho cada proceso, es decir, el tiempo desde la creación dividido entre n. Puesto que también se conoce 
el tiempo de CPU del que cada proceso ha disfrutado realmente, es fácil calcular la relación entre el 
tiempo de CPU recibido y el tiempo al que se tenía derecho. Una relación de 0.5 implica que el proceso 
sólo ha disfrutado de la mitad del tiempo al que tenía derecho, y una relación de 2.0 implica que un 
proceso ha tenido dos veces más tiempo del que debería haber tenido. El algoritmo consiste entonces en 
ejecutar el trabajo con la relación más baja hasta que su relación haya rebasado la de su competidor más 
cercano. 


2.4.6 Planificación por lotería 

Si bien hacer promesas a los usuarios y después cumplirlas es una idea admirable, es difícil de 
implementar. Podemos usar otro algoritmo para obtener resultados igualmente predecibles con una 
implementación mucho más sencilla. El algoritmo se llama planificación por lotería (Waldspurger y 
Weihl, 1994). 

La idea básica consiste en dar a los procesos boletos de lotería para los diversos recursos del sistema, 
como el tiempo de CPU. Cada vez que se hace necesario tomar una decisión de planificación, se escoge al 
azar un boleto de lotería, y el proceso poseedor de ese boleto obtiene el recurso. Cuando se aplica a la 
planificación del tiempo de CPU, el sistema podría realizar una lotería 50 veces por segundo, concediendo 
a cada ganador 20 ms de tiempo de CPU como premio. 

Parafraseando a George Orwell, “todos los procesos son iguales, pero algunos son más iguales que 
otros”. Podemos dar más boletos a los procesos más importantes, a fin de aumentar sus posibilidades de 
ganar. Si hay 100 boletos pendientes, y un proceso tiene 20 de ellos, tendrá una 
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probabilidad del 20% de ganar cada lotería. A largo plazo, obtendrá cerca del 20% del tiempo de CPU. En 
contraste con los planificadores por prioridad, donde es muy difícil establecer qué significa realmente 
tener una prioridad de 40, aquí la regla es clara: un proceso que posee una fracción de los boletos obtendrá 
aproximadamente una fracción f del recurso en cuestión. 

La planificación por lotería tiene varias propiedades interesantes. Por ejemplo, si aparece un proceso 
nuevo y se le conceden algunos boletos, en la siguiente lotería ya tendrá una probabilidad de ganar que 
será proporcional al número de boletos que recibió. En otras palabras, la planificación por lotería es de 
respuesta muy rápida. 

Los procesos cooperativos pueden intercambiar boletos si así lo desean. Por ejemplo, si un proceso 
cliente envía un mensaje a un proceso servidor y luego se bloquea, puede regalarle todos sus boletos al 
servidor, a fin de incrementar la probabilidad de que el servidor se ejecute a continuación. Una vez que el 
servidor termina, devuelve los boletos para que el cliente pueda ejecutarse otra vez. De hecho, en ausencia 
de clientes los servidores no necesitan boletos. 

Podemos usar la planificación por lotería para resolver problemas que son difíciles de manejar con 
otros métodos. Un ejemplo es un servidor de video en el que varios procesos están alimentando corrientes 
de video a sus clientes, pero con diferente velocidad. Supongamos que los procesos requieren cuadros a 
razón de 10, 20 y 25 cuadros por segundo. Si asignamos a estos procesos 10, 20 y 25 boletos, 
respectivamente, se repartirán automáticamente la CPU en la proporción correcta. 


2.4.7 Planificación en tiempo real 

Un sistema de tiempo real es uno en el que el tiempo desempeña un papel esencial. Por lo regular, uno o 
más dispositivos físicos externos a la computadora generan estímulos, y la computadora debe reaccionar a 
ellos de la forma apropiada dentro de un plazo fijo. Por ejemplo, la computadora de un reproductor de 
discos compactos recibe los bits conforme salen de la unidad de disco y los debe convertir en música 
dentro de un intervalo de tiempo muy estricto. Si el cálculo toma demasiado tiempo, la música sonará 
raro. Otros sistemas de tiempo real son los de monitoreo de pacientes en las unidades de cuidado intensivo 
de los hospitales, el piloto automático de un avión y los controles de seguridad de un reactor nuclear. En 
todos estos casos, obtener la respuesta correcta pero demasiado tarde suele ser tan malo como no 
obtenerla. 

Los sistemas de tiempo real generalmente se clasifican como de tiempo real estricto, lo que 
implica que hay plazos absolutos que deben cumplirse a como dé lugar, y tiempo real flexible, lo que 
implica que es tolerable no cumplir ocasionalmente con un plazo. En ambos casos, el comportamiento de 
tiempo real se logra dividiendo el programa en varios procesos, cada uno de los cuales tiene un 
comportamiento predecible y conocido por adelantado. Estos procesos generalmente son de corta duración 
y pueden ejecutarse hasta terminar en menos de un segundo. Cuando se detecta un suceso externo, el 
planificador debe programar los procesos de modo tal que se cumplan todos los plazos. 

Los sucesos a los que puede tener que responder un sistema de tiempo real pueden clasificarse 
también como periódicos (que ocurren a intervalos regulares) o aperiódicos (que ocurren 
de forma impredecible). Es posible que un sistema tenga que responder a múltiples corrientes 
de eventos periódicos. Dependiendo de cuánto tiempo requiere cada suceso para ser procesado, tal vez ni 
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siquiera sea posible manejarlos todos. Por ejemplo, si hay m eventos periódicos y el evento i ocurre con el 
periodo P. y requiere C segundos de tiempo de CPU para ser manejado, la carga sólo podrá manejarse si 


Un sistema de tiempo real que satisface este criterio es planificable. 

Por ejemplo, consideremos un sistema de tiempo real flexible con tres sucesos periódicos, con 
periodos de 100, 200 y 500 ms respectivamente. Si estos eventos requieren 50, 30 y 100 ms de tiempo de 
CPU por evento, respectivamente, el programa es planificable porque 0.5 + 0.15 + 0.2< 1. Si se agrega un 
cuarto evento con un periodo de 1 s, el sistema seguirá siendo planificable en tanto este evento no necesite 
más de 150 ms de tiempo de CPU por evento. Un supuesto implícito en este cálculo es que el gasto extra 
de la conmutación de contexto es tan pequeño que puede ignorarse. 

Los algoritmos de planificación de tiempo real pueden ser dinámicos o estáticos. Los primeros toman 
sus decisiones de planificación en el momento de la ejecución; los segundos las toman antes de que el 
sistema comience a operar. Consideremos brevemente unos cuantos algoritmos de planificación de tiempo 
real dinámicos. El algoritmo clásico es el algoritmo de tasa monotónica (Liu y Layland, 1973), que 
asigna por adelantado a cada proceso una prioridad proporcional a la frecuencia de ocurrencia de su 
evento disparador. Por ejemplo, un proceso que se debe ejecutar cada 20 ms recibe una prioridad de 50, y 
uno que debe ejecutarse cada 100 ms recibe una prioridad de 10. En el momento de la ejecución, el 
planificador siempre ejecuta el proceso listo que tiene la más alta prioridad, desalojando al proceso en 
ejecución si es necesario. Liu y Layland demostraron que este algoritmo es óptimo. 

Otro algoritmo de planificación en tiempo real muy utilizado es el del primer plazo más próximo. 
Cada vez que se detecta un evento, su proceso se agrega a la lista de procesos listos, la cual se mantiene 
ordenada por piazo, que en el caso de un evento periódico es la siguiente ocurrencia del evento. El 
algoritmo ejecuta el primer proceso de la lista, que es el que tiene el plazo más próximo. 

Un tercer algoritmo calcula primero para cada proceso la cantidad de tiempo que tiene de sobra, es 
decir, su holgura. Si un proceso requiere 200 ms y debe terminar en un plazo de 250 ms, tiene una 
holgura de 50 ms. El algoritmo, llamado de menor holgura, escoge el proceso que tiene menos tiempo de 
sobra. 

Si bien en teoría es posible convertir un sistema operativo de aplicación general en uno de tiempo 
real usando uno de estos algoritmos de planificación, en la práctica el gasto extra de la conmutación de 
contexto de los sistemas de aplicación general es tan grande que el desempeño de tiempo real sólo puede 
lograrse en aplicaciones con restricciones de tiempo muy holgadas. En consecuencia, en la mayor parte de 
los trabajos en tiempo real se usan sistemas operativos de tiempo real especiales que tienen ciertas 
propiedades importantes. Por lo regular, éstas incluyen un tamaño pequeño, un tiempo de interrupción 
rápido, una conmutación de contexto rápida, un intervalo corto durante el cual se inhabilitan las 
interrupciones, y la capacidad para controlar múltiples cronómetros con precisión de milisegundos o 
microsegundos. 
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2.4.8 Planificación de dos niveles 

Hasta ahora más o menos hemos supuesto que todos los procesos ejecutables están en la memoria 
principal. Si la memoria principal disponible no es suficiente, algunos de los procesos ejecutables tendrán 
que mantenerse en el disco total o parcialmente. Esta situación tiene implicaciones importantes para la 
planificación, ya que el tiempo de conmutación de procesos cuando hay que traer los procesos del disco es 
varios órdenes de magnitud mayor que cuando la conmutación es a un proceso que ya está en la memoria. 

Una forma más práctica de manejar los procesos intercambiados a disco es el uso de un planificador 
de dos niveles. Primero se carga en la memoria principal un subconjunto de los procesos ejecutables, 
como se muestra en la Fig. 2-25(a). Luego, el planificador se ¡imita a escoger procesos de este 
subconjunto durante cierto tiempo. Periódicamente se invoca un planificador de nivel superior para 
eliminar los procesos que han estado en memoria suficiente tiempo y cargar procesos que han estado en el 
disco demasiado tiempo. Una vez efectuado el cambio, como en la Fig. 2-25(b), el planificador de bajo 
nivel otra vez se ¡imita a ejecutar procesos que están en la memoria. Así, este planificador se ocupa de 
escoger entre los procesos ejecutables que están en la memoria en ese momento, mientras el planificador 
de nivel superior se ocupa de trasladar procesos entre la memoria y el disco. 
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Figura 2-25. Un planificador de dos niveles debe transferir procesos entre el disco y la 
memoria y también escoger los procesos a ejecutar de entre los que están en la memoria 
Representamos tres diferentes instantes con (a), (b) y (c). 


Entre los criterios que el planificador de nivel superior podría usar para tomar sus decisiones están 
los siguientes: 

1. ¿Cuánto tiempo hace que el proceso se intercambió del o al disco? 

2. ¿Cuánto tiempo de CPU ha recibido el proceso recientemente? 

3. ¿Qué tan grande es el proceso? (Los pequeños no estorban.) 

4. ¿Qué tan alta es la prioridad del proceso? 


Aquí también podríamos usar planificación round robín, por prioridad o por cualquiera de varios otros 
métodos. Los dos planificadores podrían usar el mismo algoritmo o algoritmos distintos. 
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2.4.9 Política vs. mecanismo 

Hasta ahora, hemos supuesto tácitamente que todos los procesos del sistema pertenecen a diferentes 
usuarios y, por tanto, están compitiendo por la CPU. Si bien esto es conecto en muchos casos, a veces 
sucede que un proceso tiene muchos hijos ejecutándose bajo su control. Por ejemplo, un proceso de 
sistema de administración de bases de datos podría tener muchos hijos. Cada hijo podría estar atendiendo 
una solicitud distinta, o cada uno podría tener una función específica qué realizar (análisis sintáctico de 
consultas, acceso a disco, etc.). Es muy posible que el proceso principal tenga una idea excelente de cuáles 
de sus hijos son los más importantes (o para los que el tiempo es más crítico) y cuáles son los menos 
importantes. Desafortunadamente, ninguno de los planificadores que hemos visto aceptan entradas de los 
procesos de usuario relacionadas con las decisiones de planificación. Por tanto, el planificador casi nunca 
toma la mejor decisión. 

La solución a este problema consiste en separar el mecanismo de planificación de la política de 
planificación. Esto significa que el algoritmo de planificación se regula de alguna manera mediante 
parámetros, y que estos parámetros pueden ser proporcionados por procesos de usuario. Consideremos 
otra vez el ejemplo de base de datos. Supongamos que el kemel usa un algoritmo de planificación por 
prioridad pero ofrece una llamada al sistema mediante el cual un proceso puede establecer (y modificar) 
las prioridades de sus hijos. De este modo, el padre puede controlar detalladamente la forma como sus 
hijos se planifican, aunque él en sí no realiza la planificación. Aquí el mecanismo está en el kemel pero la 
política es establecida por un proceso de usuario. 


2.5 PERSPECTIVA GENERAL DE PROCESOS EN MINIX 

Ahora que hemos completado nuestro estudio de los principios de la administración de procesos, la 
comunicación entre procesos y la planificación, daremos un vistazo a la forma como se aplican en MINIX. 
A diferencia de UNIX, cuyo kemel es un programa monolítico que no está dividido en módulos, MINIX 
es una colección de procesos que se comunican entre sí y con los procesos de usuario empleando una sola 
primitiva de comunicación entre procesos: la transferencia de mensajes. Este diseño confiere una 
estructura más modular y flexible y hace más fácil, por ejemplo, reemplazar todo el sistema de archivos 
por uno totalmente distinto, sin tener siquiera que recompilar el kemel. 


2.5.1 La estructura interna de MINIX 

Comencemos nuestro estudio de MINIX con una mirada a vuelo de pájaro del sistema. MINIX está 
estructurado en cuatro capas, cada una de las cuales realiza una función bien definida. Las cuatro capas se 
ilustran en la Hg. 2-26. 

La capa inferior atrapa todas las interrupciones y trampas, realiza la planificación y ofrece a 
las capas superiores un modelo de procesos secuenciales independientes que se comunican empleando 
mensajes. El código de esta capa tiene dos funciones principales. La primera 
es atrapar las interrupciones y trampas, guardar y restaurar registros, planificar, y las demás tareas de bajo 
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Figura 2-26. MIN1X está estructurado en cuatro capas. 


nivel necesarias para que funcione la abstracción de procesos que se presenta a las capas superiores. La 
segunda es manejar los aspectos mecánicos de los mensajes; verificar que los destinos sean válidos, ubicar 
los buffers de envío y recepción en la memoria física, y copiar bytes del emisor al receptor. La parte de la 
capa que se ocupa del nivel más bajo del manejo de interrupciones se escribe en lenguaje ensamblador. El 
resto de la capa y todas las demás capas de arriba se escriben en C. 

La capa 2 contiene los procesos de E/S, uno por cada tipo de dispositivo. A fin de distinguirlos de 
los procesos de usuario ordinarios, los llamaremos tareas, pero las diferencias entre tareas y procesos son 
mínimas. En muchos procesos las tareas de entrada/salida se denominan manejado- res de dispositivos; 
usaremos los términos “tarea” y “manejador de dispositivo” indistintamente. Se requiere una tarea para 
cada tipo de dispositivo, incluidos discos, impresoras, terminales, interfaces de red y relojes. Si están 
presentes otros dispositivos de E/S, se necesitará también una tarea para cada uno. Una de las tareas, la de 
sistema, es un poco distinta, ya que no corresponde a ningún dispositivo de E/S. Estudiaremos las tareas 
en el próximo capítulo. 

Todas las tareas de la capa 2 y todo el código de la capa 1 se combinan para formar un solo 
programa binario llamado kemel. Algunas de las tareas comparten subrutinas comunes, pero por lo demás 
son independientes, se planifican por separado y se comunican usando mensajes. Los procesadores Intel a 
partir del 286 asignan uno de cuatro niveles de privilegio a cada proceso. Aunque las tareas y el kemel se 
compilan juntos, cuando el kemel y los manejadores de interrupciones se están ejecutando tienen más 
privilegios que las tareas. Así, el verdadero código de kemel puede acceder a cualquier parte de la 
memoria y a cualquier registro de procesador; en esencia, el kemel puede ejecutar cualquier instrucción 
usando datos de cualquier parte del sistema. Las tareas no pueden ejecutar todas las instrucciones de nivel 
de máquina, y tampoco pueden acceder a todos los registros de la CPU ni a todas las direcciones de 
memoria. Sin embargo, sí pueden acceder a regiones de la memoria que pertenecen a procesos menos 
privilegiados, con objeto de realizar E/S para ellos. Una tarea, la de sistema, no efectúa E/S en el sentido 
usual, sino que existe con el fin de proveer servicios, como el copiado entre diferentes regiones de la 
memoria, a procesos que no pueden hacer este tipo de cosas por sí mismos. Desde luego, en las máquinas 
que no proporcionan diferentes niveles de privilegio, como los procesadores Intel más antiguos, no es 
posible hacer que se cumplan estas restricciones. 
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La capa 3 contiene procesos que proporcionan servicios útiles a los procesos de usuario. Estos 
procesos servidores se ejecutan en un nivel menos privilegiado que el kemel y las tareas, y no pueden 
acceder directamente a los puertos de E/S. Estos procesos tampoco pueden acceder a la memoria fuera de 
los segmentos que les son asignados. El administrador de memoria (MM) ejecuta todas las llamadas al 
sistema de MINIX que intervienen en la administración de la memoria, como FORK, EXEC y BRK. El 
sistema de archivos (FS) ejecuta todas las llamadas al sistema relacionadas con archivos, como READ, 
MOUNT y CHDIR. 

Como señalamos al principio del capítulo 1, los sistemas operativos hacen dos cosas: administran 
recursos y proporcionan una máquina extendida implementando llamadas al sistema. En MINIX la 
administración de recursos reside en gran medida en el kemel (capas 1 y 2), y la interpretación de las 
llamadas al sistema está en la capa 3. El sistema de archivos se diseñó como “servidor” de archivos y se 
puede trasladar a una máquina remota casi sin cambios. Esto se aplica también al administrador de 
memoria, aunque los servidores de memoria remotos no son tan titiles como los servidores de archivos 
remotos. 

Pueden existir servidores adicionales en la capa 3. En la Fig. 2-26 se muestra ahí un servidor de red. 
Aunque MINIX, tal como se describe en este libro, no incluye el servidor de red, su código fuente forma 
parte de la distribución MINIX estándar; el sistema se puede recompilar fácilmente para incluirlo. 

Éste es un buen lugar para mencionar que, si bien los servidores son procesos independientes, 
difieren de los procesos de usuario en cuanto a que se inician cuando el sistema se inicia, y nunca 
terminan mientras el sistema está activo. Además, aunque los servidores se ejecutan en el mismo nivel de 
privilegio que los procesos de usuario en términos de las instrucciones de máquina que tienen permitido 
ejecutar, reciben prioridad de ejecución más alta que los procesos de usuario. Si se desea incluir un nuevo 
servidor es necesario recompilar el kemel. El código de arranque del kemel instala los servidores en 
ranuras privilegiadas de la tabla de procesos antes de permitir que se ejecute cualquier proceso de usuario. 

Por último, la capa 4 contiene todos los procesos de usuario: shells, editores, compiladores y 
programas a.out escritos por el usuario. Un sistema en ejecución por lo regular tiene algunos procesos que 
se inician cuando el sistema arranca y que se ejecutan indefinidamente. Por ejemplo, un demonio es un 
proceso de segundo plano que se ejecuta periódicamente o que espera continuamente algún evento, como 
la llegada de un paquete por la red. En cierto sentido, un demonio es un servidor que se inicia 
independientemente y se ejecuta como proceso de usuario. Sin embargo, a diferencia de los verdaderos 
servidores instalados en ranuras privilegiadas, tales programas no pueden recibir por parte del kemel el 
tratamiento especial que reciben los procesos servidores de memoria y de archivos. 


23.2 Administración de procesos en MINIX 

Los procesos en MINIX siguen el modelo general de procesos que describimos con cierto detalle al 
principio del capítulo. Los procesos pueden crear subprocesos, que a su vez pueden crear más 
subprocesos, produciendo un árbol de procesos. De hecho, todos los procesos de usuario del sistema 
forman parte de un solo árbol con mit (véase la Fig. 2-26) en su raíz. 
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¿Cómo surge esta situación? Cuando se enciende la computadora, el hardware lee el primer sector 
de la primera pista del disco de arranque y lo coloca en la memoria, y luego ejecuta el código que 
encuentra ahí. Los detalles varían dependiendo de si el disco de arranque es un disquete o el disco duro. 
En un disquete este sector contiene el programa de autoarranque (bootstrap), que es muy pequeño, pues 
debe caber en un sector. El autoarranque de MINIX carga un programa más grande, boot, que luego carga 
el sistema operativo propiamente dicho. 

En cambio, los discos duros requieren un paso intermedio. Un disco duro está dividido en 
particiones, y el primer sector de un disco duro contiene un pequeño programa y la tabla de particiones del 
disco. Colectivamente, éstos se conocen como registro maestro de arranque. La parte de programa se 
ejecuta para leer la tabla de particiones y seleccionar la partición activa, la cual tiene un autoarranque en 
su primer sector, mismo que se carga y ejecuta para encontrar e iniciar una copia de boot en la partición, 
exactamente como se hace cuando se arranca con un disquete. 

En ambos casos, boot busca un archivo multipartes en el disquete o la partición y carga las partes 
individuales en las posiciones apropiadas de la memoria. Estas partes incluyen el kemel, el administrador 
de memoria, el sistema de archivos e mit, el primer proceso de usuario. Este proceso de arranque no es 
una operación trivial. Las operaciones pertenecientes al ámbito de la tarea de disco y el sistema de 
archivos deben ser ejecutadas por boot antes de que estas partes del sistema queden activas. En una 
sección posterior volveremos al tema de cómo se inicia MINIX. Por ahora baste decir que una vez 
terminada la operación de carga el kemel comienza a ejecutarse. 

Durante su fase de inicialización, el kemel inicia las tareas, y luego el administrador de memoria, el 
sistema de archivos y cualesquiera otros servidores que se ejecuten en la capa 3. Una vez que todos éstos 
se han ejecutado e inicializado a sí mismos, se bloquean, esperando algo que hacer. Una vez que todas las 
tareas y servidores están bloqueados, se ejecuta mit, el primer proceso de usuario. Este proceso ya está en 
la memoria principal, pero desde luego podría haberse cargado del disco como programa aparte, ya que 
todo está funcionando para cuando se inicia. Sin embargo, dado que mit se inicia sólo esta única vez y 
nunca se vuelve a cargar del disco, lo más fácil es incluirlo en el archivo de imagen del sistema junto con 
el kemel, las tareas y los servidores. 

Lo primero que init hace es leer el archivo /etc/ttvrab, que lista todos los dispositivos de terminal 
potenciales. Los dispositivos que pueden usarse como ter mi nales de inicio de sesión (en la distribución 
estándar, sólo la consola) tienen una entrada en el campo getty de /etc/ttytab, e mit bifurca un proceso hijo 
para cada una de esas terminales. Normalmente, cada hijo ejecuta /usr/ bin/getty que exhibe un mensaje y 
luego espera que se teclee un nombre. Luego se invoca lusribini login con ese nombre como argumento. Si 
una terminal en particular requiere un tratamiento especial (p. ej., una línea de marcado telefónico), 
/etc/ttytab puede especificar un comando (como /usr/bin/stzy) que se ejecutará para inicializar la línea 
antes de ejecutar getty. 

Si se inicia la sesión con éxito, Ibm/login ejecuta el shell del usuario (especificado en el archivo 
/etc/passwd, y que normalmente es /binlsh o /usr/bin/ash). El shell espera que se tecleen comandos y luego 
bifurca un nuevo proceso para cada comando. De este modo, los shelis son los hijos de mit, los procesos 
de usuario son los nietos de mit, y todos los procesos de usuario del sistema forman parte de un mismo 
árbol. 
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Las dos principales llamadas al sistema para administración de sistemas en MINIX son FORK y 
EXEC. FORK es la única forma de crear un proceso nuevo. EXEC permite a un proceso ejecutar un 
programa especificado. Cuando se ejecuta un programa, se le asigna una porción de memoria cuyo tamaño 
está especificado en la cabecera del archivo del programa. El programa conserva esta cantidad de memoria 
durante toda su ejecución, aunque la distribución entre segmento de datos, segmento de pila y espacio no 
utilizado puede variar durante la ejecución del proceso. 

Toda la in formación referente a un proceso se guarda en la tabla de procesos, que se divide entre el 
kemel, el administrador de memoria y el sistema de archivos. Cada uno de éstos tiene los campos que 
necesita. Cuando nace un proceso nuevo (por FORK), o un proceso viejo termina (por EXrr o una señal), 
el administrador de memoria actualiza su parte de la tabla de procesos y luego envía mensajes al sistema 
de archivos y al kemel diciéndoles que hagan lo propio. 


2.5.3 Comunicación entre procesos en MINIX 

Se cuenta con tres primitivas para enviar y recibir mensajes, las cuales se invocan con los procedimientos 
de biblioteca de C 

send(destino, &mensaje); 

para enviar un mensaje al proceso destino, 

receive(origen, &mensaje); 

para recibir un mensaje del proceso origen (o ANY) y 
send_rec(org_dest, &mensaje); 

para enviar un mensaje y esperar una respuesta del mismo proceso. El segundo parámetro en todas estas 
llamadas es la dirección local de los datos del mensaje. El mecanismo de transferencia de mensajes del 
kemel copia el mensaje del emisor al receptor. La respuesta (en el caso de send rec) sobreescribe el 
mensaje original. En principio, este mecanismo del kemel podría ser reemplazado por una función que 
copia mensajes a través de una red a una función correspondiente en otra máquina, a fin de implementar 
un sistema distribuido. En la práctica esto se complicaría un poco por el hecho de que el contenido de los 
mensajes a veces es un apuntador a una estructura de datos grande, y un sistema distribuido tendría que 
incluir una forma de copiar los datos mismos por la red. 

Cada proceso o tarea puede enviar y recibir mensajes de procesos y tareas de su propia capa, y de 
aquellos en la capa que está directamente abajo. Los procesos de usuario no pueden comunicarse 
directamente con las tareas de E/S. El sistema obliga a cumplir esta restricción. 

Cuando un proceso (lo que también incluye las tareas como caso especial) envía un mensaje aun proceso 
que actualmente no está esperando un mensaje, el emisor se bloquea hasta que el destino ejecuta 
RECEIVE. En otras palabras, MINIX usa el método de cita para evitar los problemas almacenar 
temporalmente los mensajes enviados que todavía no se han recibido. Aunque esto emenos flexible que un 
esquema con buffers, resulta ser suficiente para este sistema, y mucho más sencillo, ya que no se requiere 
administración de buffers. 
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2.5.4 Planificación de procesos en MINIX 

El sistema de interrupciones es lo que mantiene funcionando a un sistema operativo con 
multiprogramación. Los procesos se bloquean cuando solicitan entradas, permitiendo la ejecución de otros 
procesos. Una vez que están disponibles las entradas, el disco, el teclado u otro hardware interrumpe el 
proceso que se está ejecutando. El reloj también genera interrupciones que sirven para asegurar que un 
proceso de usuario en ejecución que no haya solicitado entradas tarde o temprano ceda la CPU para que 
otros procesos tengan oportunidad de ejecutarse. Es obligación de la capa más baja de MINIX ocultar 
estas interrupciones convirtiéndolas en mensajes. En lo que a los procesos (y mensajes) concierne, cuando 
un dispositivo de E/S completa una operación envía un mensaje a algún proceso, despertándolo y 
haciéndolo ejecutable. 

Cada vez que un proceso es interrumpido, sea por un dispositivo de E/S convencional o por el reloj, 
surge la oportunidad de volver a determinar cuál proceso es el que más merece una oportunidad de 
ejecutarse. Desde luego, esto debe hacerse también cada vez que un proceso termina, pero en un sistema 
como MINIX las interrupciones causadas por operaciones de E/S o el reloj ocurren con mucha mayor 
frecuencia que la terminación de procesos. El planificador de MINIX usa un sistema de colas multinivel 
con tres niveles, que corresponden a las capas 2, 3 y 4 de la Fig. 2-26. Dentro de los niveles de tareas y 
servidores los procesos se ejecutan hasta que se bloquean, pero los procesos de usuario se planifican round 
robín. Las tareas tienen la prioridad más alta, les siguen el administrador de memoria y el servidor de 
archivos, y los procesos de usuario vienen al final. 

Al escoger el proceso que se va a ejecutar, el planificador verifica si hay alguna tarea lista. Si una o 
más están listas, se ejecuta la que esté a la cabeza de la cola. Si no hay tareas listas, se escoge un servidor 
(MM o FS), si es posible; en caso contrario, se ejecuta un proceso de usuario, Si no hay ningún proceso 
listo, se escoge el proceso IDLE. Éste es un ciclo que se ejecuta hasta que ocurre la siguiente interrupción. 

En cada tic del reloj, se verifica si el proceso en curso es un proceso de usuario que se ha ejecutado 
durante más de 100 ms. Si así es, se invoca el planificador para ver si hay otro proceso de usuario 
esperando la CPU. Si se encuentra uno, el proceso actual se pasa al final de su cola de planificación y se 
ejecuta el proceso que está a la cabeza de dicha cola. Las tareas, el administrador de memoria y el sistema 
de archivos nunca son desalojados por el reloj, aunque se hayan estado ejecutando durante mucho tiempo. 


2.6 IMPLEMENTACIÓN DE PROCESOS EN MINIX 

Ya nos estamos acercando al momento en que examinaremos el código real, así que es pertinente incluir 
aquí unas cuantas palabras acerca de la notación que usaremos. Los términos “procedimiento”, “función” 
y “rutina” se usarán indistintamente. Los nombres de variables, procedimientos y archivos se escribirán en 
cursivas, como en rw flag. Cuando un nombre de variable, procedimiento o archivo inicie una oración, se 
escribirá con mayúscula, pero todos los nombres reales comienzan con minúsculas. Las llamadas al 
sistema estarán en versalitas, como READ. 
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El libro y el software, que están en continua evolución, no se “fueron a la imprenta” el mismo día, 
así que puede haber discrepancias menores entre las referencias al código, el listado impreso y la versión 
en CD-ROM. Sin embargo, tales diferencias generalmente sólo afectan una o dos líneas. Además, el 
código fuente aquí impreso se simplificó eliminando el que se usó para compilar opciones que no se 
explican en el libro. 


2.61 Organización del código fuente de MINIX 

Lógicamente, el código fuente está organizado en dos directorios. Las rutas completas a estos directorios 
en un sistema MINIX estándar son /usr/include/ y /usr/src/ (una diagonal final en un nombre de ruta indica 
que se refiere a un directorio). La ubicación real de los directorios puede variar de un sistema a otro, pero 
normalmente la estructura de los directorios por debajo del nivel más alto es la misma en todos los 
sistemas. Nos referiremos a estos directorios como inelude/ y src/ en este texto. 

El directorio inelude/ contiene varios archivos de cabecera Posix estándar; además, tiene tres 
subdirectorios: 

1. sys/ — este subdirectorio contiene cabeceras Pos adicionales. 

2. minix/ — incluye archivos de cabecera utilizados por el sistema operativo. 

3. ibm/ — incluye archivos de cabecera con definiciones específicas para IBM-PC. 


A fin de manejar extensiones de MINIX y programas que se ejecutan en el entorno MINIX, hay otros 
directorios presentes en inelude/ en la versión proporcionada en el CD-ROM o por Internet. Por ejemplo, 
el directorio include/neti y su subdirectorio include/net/gen/ apoyan las extensiones de red. Sin embargo, 
en este texto sólo se imprimirán y explicarán los archivos necesarios para compilar el sistema MINIX 
básico. 

El directorio src/ contiene tres subdirectorios importantes en los que se encuentra el código fuente 
del sistema operativo: 


1. kemel/ — capas 1 y 2 (procesos, mensajes y controladores). 

2. mm/ — el código del administrador de memoria. 

3. fs/ —el código del sistema de archivos. 

Hay otros tres directorios de código fuente que no se imprimen ni explican en el texto, pero que son 
esenciales para producir un sistema funcional: 


1. src/lib/ — código fuente de los procedimientos de biblioteca (p. ej., open, read). 

2. src/tools/ — código fuente del programa mit, con el que se inicia MINIX. 

3. scr/boot/ — código para arrancar e instalar MINIX. 

La distribución estándar de MINIX incluye varios directorios fuente más. Desde luego, un 
sistema operativo existe para apoyar los comandos (programas) que se ejecutarán en él, así que hay un 
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directorio src/commands/ de gran tamaño con el código fuente para los programas de utilidad (p. ej., cat, 
cp, date, is, pwd). Puesto que MINIX es un sistema operativo educativo modificable, existe un directorio 
src/test/ con programas diseñado para probar exhaustivamente un sistema MINIX recién compilado. Por 
último, el directorio /src/inet/ incluye código fuente para recompilar MINIX con apoyo de red. 

Por comodidad normalmente nos referiremos a los nombres de archivo simples si por el contexto 
queda claro cuál es el nombre completo de la ruta. No obstante, cabe señalar que algunos nombres de 
archivo aparecen en más de un directorio. Por ejemplo, hay varios archivos llamados const. h en los que se 
definen constantes pertinentes a una parte específica del sistema. Los archivos de un directorio en 
particular se explicarán juntos, así que no debería haber confusiones. Los archivos se listan en el apéndice 
A en el orden en que se explican en el texto, a fin de que sea más fácil seguir las explicaciones. En este 
punto podría ser una buena idea conseguir un par de señaladores para poder pasar fácilmente de una parte 
del libro a otra. 

También vale la pena señalar que el apéndice B contiene la lista alfabética de todos los archivos 
descritos en el apéndice A, y el apéndice C contiene una lista de dónde pueden encontrarse las 
definiciones de macros, variables globales y procedimientos empleados en MINIX. 

El código para las capas 1 y 2 está contenido en el directorio src/kemel/. En este capítulo 
estudiaremos los archivos de este directorio que apoyan la administración de procesos, la capa más baja de 
la estructura de MINIX que vimos en la Fig. 2-26. Esta capa incluye funciones que se encargan de la 
inicialización del sistema, las interrupciones, la transferencia de mensajes y la planificación de procesos. 
En el capítulo 3 veremos el resto de los archivos de este directorio, los cuales apoyan las diversas tareas, 
mismas que constituyen la segunda capa de la Fig. 2-26. En el capítulo 4 examinaremos los archivos del 
administrador de memoria que están en src/mm./, y en el capítulo 5 estudiaremos el sistema de archivos, 
cuyos archivos fuente se encuentran en src/fs/. 

Una vez que MINIX se compila, todos los archivos de código fuente de src/kemel/, src/mml y 
src/fs/ producen archivos objeto. Todos los archivos objeto de src/kemel/ se enlazan para formar un solo 
programa ejecutable, kemel. Los archivos objeto de src/mm/ también se enlazan para formar un solo 
programa ejecutable, mm, y algo análogo sucede con fs. Se pueden agregar extensiones incluyendo 
servidores adicionales; por ejemplo, el apoyo de red se agrega modificando include/minix/config.h a modo 
de habilitar la compilación de los archivos de src/inet/, que constituirán inet. Otro programa ejecutable, in 
it, se construye en src/toolst El programa installboot (cuya fuente está en src/boot/) agrega nombres a cada 
uno de estos programas, los rellena de modo que su longitud sea un múltiplo del tamaño de un sector del 
disco (a fin de facilitar la carga independiente de las partes) y los concatena para formar un solo archivo. 
Este nuevo archivo es el binario del sistema operativo y puede copiarse en el directorio raíz o en el 
directorio Iminixl de un disco flexible o de una partición del disco duro. Posteriormente, el programa 
monitor del arranque podrá cargar y ejecutar el sistema operativo. En la Fig. 2-27 se muestra la 
organización de la memoria después de que los programas concatenados se han separado y cargado. Desde 
luego, los detalles dependen de la configuración del sistema. El ejemplo de la figura es para un 
sistema MINIX configurado a modo de aprovechar una computadora equipada con varios megabytes 
de memoria. Esto hace posible repartir un gran número de buffers del sistema de archivos, 
pero el sistema de archivos resultante es demasiado grande para caber en el intervalo inferior de la memo- 
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ría. por debajo de los 640K. Si el número de buffers se reduce drásticamente, es posible lograr que lado el 
sistema quepa en menos de 640K de memoria, con espacio incluso para unos cuantos procesos de usuario. 


we/tools/imt 
src/inet/inet (opcional) 


•rc/mnVmml 


•rc/kemaVfcamei 


Memoria disponible 
para programas 
de usuario 


Sistema de archivos 


Administrador de memoria 



Memoria 
disponible para 
programas de usuario 


Tarea de Ethernet 


Tarea de impresora 


Tarea de terminal 


Tarea de memoria 


Tarea de disco 


Vectores de interrupciones 


Limite de la memoria 


2383 K 
2372 K 

2198 K (Depende del número 
de bulfers incluidos 
en el sistema de archivos) 

1077 K 
1024 K 


640 K 


129 K (Depende del número 
de tareas de E/S) 


2 K 
1 K 


0 


Figura 2-27. Organización de la memoria después de que MINIX se ha cargado del disco a la 
memoria. Las cuatro (o cinco, con el apoyo de red) panes, compiladas independientemente 
y enlazadas, son obviamente distintas. Los tamaAos son aproximados, dependiendo de la 
configuración. 


Es importante percatarse de que MINIX consiste en tres o más programas totalmente independientes que 
sólo se comunican entre sí por medio de mensajes. Un procedimiento llamado sic en src/fs/ no 
entra en conflicto con otro del mismo nombre en src/mm/ porque en última instancia 
se enlazan dentro de diferentes archivos ejecutables. Los únicos procedimientos 
que tienen en común los tres componentes del sistema operativo son unas cuantas de las rutinas de 
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biblioteca que están en lib/. Esta estructura modular hace que sea muy fácil modificar, digamos, el sistema 
de archivos sin que los cambios realizados afecten el administrador de memoria; además hace que no sea 
complicado quitar todo el sistema de archivos y colocarlo en una máquina distinta como servidor de 
archivos que se comunicará con las máquinas usuarias enviando mensajes por una red. 

Como ejemplo adicional de la modularidad de MINIX, al administrador de memoria y al sistema de 
archivos les da exactamente lo mismo si el sistema se compila con o sin apoyo de red, y el kemel sólo 
resulta afectado porque la tarea de Ethernet se compila ahí, junto con el apoyo para otros dispositivos de 
E/S. Una vez habilitado, el servidor de red se integra al sistema MINIX como servidor con el mismo nivel 
de prioridad que el administrador de memoria o el servidor de archivos. Su funcionamiento puede implicar 
la transferencia de grandes cantidades de datos con gran rapidez, y esto requiere una prioridad más alta 
que la que recibiría un proceso de usuario. Sin embargo, con excepción de la tarea de Ethernet, las 
funciones de red podrían llevarse a cabo con procesos en el nivel de usuario. Tales funciones no son 
tradicionalmente funciones del sistema operativo, y una explicación detallada del código de red rebasa el 
alcance de este libro. En secciones y capítulos subsecuentes las explicaciones se basarán en un sistema 
MINIX compilado sin apoyo de red. 


2.6.2 Los archivos de cabecera común 

El directorio inelude/ y sus subdirectorios contienen una colección de archivos que definen constantes, 
macros y tipos. La norma iosix requiere muchas de estas definiciones y especifica en qué archivos del 
directorio principal inelude/ y de su subdirectorio includ/sys/ se encuentra cada una de las definiciones 
obligatorias. Los archivos de estos directorios son archivos de cabecera o de inclusión, identificados por el 
sufijo .h, y se incluyen mediante instrucciones #include en los archivos fuente en C. Estas instrucciones 
son una característica del lenguaje C. Los archivos de inclusión facilitan el manteni mi ento de los sistemas 
grandes. 

Las cabeceras que probablemente se necesitarán para compilar programas de usuario se encuentran 
en inelude/, mientras que include/sys/ tradicionalmente se ha usado para archivos que sirven 
principalmente para compilar programas del sistema y de rutinas de utilidad. La distinción no es 
demasiado importante, y una compilación típica, sea de un programa de usuario o de una parte del sistema 
operativo, incluirá archivos de ambos directorios. Aquí veremos los archivos que se necesitan para 
compilar el sistema MINIX estándar, examinando primero los que están en inelude! y luego los que están 
en include/syst En la siguiente sección hablaremos de todos los archivos de los directorios include/minix/ 
e include/ibml que, como indican los nombres de directorio, son exclusivos de MINIX y de su 
implementación en computadoras tipo IBM. 

Las primeras cabeceras que consideraremos son en verdad de aplicación general, al grado de que 
ninguno de los archivos fuente en C para el sistema MINIX hace referencia directamente a ellas; 
más bien, están incluidas en otros archivos de cabecera, las cabeceras maestras src/kemel/kemel.h, 
src/mm/mm.h y src/fs/fs.h para cada una de las tres partes principales del sistema MINIX, que a 
su vez se incluyen en todas las compilaciones. Cada cabecera maestra está adaptada a 
las necesidades de la parte correspondiente del sistema MINIX, pero todas comienzan con 
una sección como la que se muestra en la Fig. 2-28. Hablaremos más de las cabeceras maestras en otras 
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#foclude <minix/conf¡g.h> 


/* DEBE ser el primero V 
/* DEBE ser el segundo 7 


ánclude <ansi.h> 


dndutJe <sys/typesh> 
flnciucJe <minix/con$t.h> 

#ndude <mirxx/type.h> 

Dndude <limits ,h> 
flftclude <ermo.h> 
flndude <minix/syslib.h> 

ligara 2-28. Parte de una cabecera maestra que asegura la inclusión de los archivos de 
cabecera que todos los archivos fuente en C necesitan. 


secciones del libro. Este avance tiene como propósito subrayar el hecho de que se juntan cabeceras de 
varios directorios. En esta sección y en la siguiente mencionaremos cada uno de los archivos a los que se 
hace referencia en la Fig. 2-2 8. 

Comencemos con la primera cabecera de inelude/, ansi.h (línea 0000). Ésta es la segunda cabecera 
que se procesa cada vez que se compila una parte del sistema MINIX; sólo include/minix/config.h se 
procesa antes. El propósito de ansi.h es probar si el compilador satisface los requisitos de Standard C, 
definidos por la Organización Internacional de Normas (ISO). Standard C también se flama ANSI C, 
puesto que el estándar fue creado originalmente por el American National Standards Institute antes de 
adquirir reconocimiento internacional. Un compilador de Standard C define varias macros que pueden 

probarse después en los programas que se compilan._STDC_es una de esas macros, y un compilador 

estándar la define con un valor de 1, igual que si el weprocesador de C hubiera leído una línea como 

#define_STDC _1 

El compilador distribuido con las versiones actuales de MINIX se ajusta al Standard C, pero las versiones 
antiguas de MINIX se crearon antes de la adopción del estándar y aun es posible compilar MINI con un 
compilador de C clásico (Kemighan & Ritchie). Se pretende que MINIX sea fácil de trasladar a máquinas 
nuevas, y permitir compiladores antiguos es parte de esta política. En las líneas 0023 a 0025 se procesa la 
i ns trucción 


#define _ANSI 

si se está usando un compilador de Standard C. Ansi.h define varias macros de diferentes formas, 
dependiendo de si está definida o no la macro ANSI. 

La macro más importante de este archivo es PROTOTYPE. Esta macro nos permite escribir 
prototipos de funciones de la forma 


PROTOTYPE (tipodevuelto, nombrefunc, (tipo argumento argumento,...)) 
y que el preprocesador de C los transforme en 
tipo devuelto nombre_fimc(tipo-argumento, argumento,...) 
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si el compilador es de ANSI Standard C, o 
tipodevuelto nombre_fúnc() 

si el compilador es del tipo antiguo (Kemighan & Ritchie). 

Antes de dejar ansi.h mencionaremos otra característica. Todo el archivo está delimitado por líneas 
que dicen 

#ifndef_ANSI_H 

y 

#endif 

En la línea que sigue inmediatamente a #ifndef, se define ANSLH misma. Un archivo de cabecera sólo 
debe incluirse una vez en una compilación; esta construcción asegura que se hará caso omiso del 
contenido del archivo si se le incluye más de una vez. Veremos que se usa esta técnica en todos los 
archivos de cabecera del directorio inelude/. 

El segundo archivo de inelude/ que se incluye indirectamente en todos los archivos fuente de MINIX 
es la cabecera limits,h (línea 0100). Este archivo define muchos tamaños básicos, tanto de tipos del 
lenguaje como el número de bits de un entero, así como límites del sistema operativo como la longitud de 
un nombre de archivo. Ermo.h (línea 0200) también es incluido por todas las cabeceras maestras; contiene 
los números de error devueltos a los programas de usuario en la variable global ermo cuando una llamada 
al sistema falla. También se usa ermo para identificar algunos errores intemos, como un intento por enviar 
un mensaje a una tarea inexistente. Los números de error son negativos para marcarlos como códigos de 
error dentro del sistema MINIX, pero deben convertirse en positivos antes de devolverse a los programas 
de usuario. El truco que se usa es que cada código de error se define en una línea como 

#define EPERM (S1GN 1) 

(línea 0236). La cabecera maestra de cada parte del sistema operativo define la macro SYSTEM, pero 
ésta nunca se define cuando se compila un programa de usuario. Si se define SYSTEM, entonces SIGN 
se define como “—“; en caso contrario, se le da una definición nula. 

El siguiente grupo de archivos que consideraremos no se incluye en todas las cabeceras maestras, 
pero de todos modos se usa en muchos archivos fuente en todas las partes del sistema MINIX. El más 
importante es unistd.h (línea 0400). Esta cabecera define muchas constantes, la mayor parte de las cuales 
son requeridas por posix. Además, unistd.h incluye prototipos de muchas fúnciones en C, incluidas todas 
las que se usan para acceder a las llamadas al sistema de MINIX. Otro archivo que se utiliza mucho es 
string.h (línea 0600), que incluye prototipos de muchas funciones en C que sirven para manipular cadenas. 
La cabecera signal.h (línea 0700) define los nombres de las señales estándar, y también contiene 
prototipos de algunas fúnciones relacionadas con señales. Como veremos después, en el manejo de señales 
intervienen todas las partes de MINIX. 

Fcntl. h (línea 0900) define simbólicamente muchos parámetros empleados en operaciones de 
control de archivos. Por ejemplo, este archivo nos permite usar la macro O RDONLY en lugar del valor 
numérico O como parámetro de una llamada open. Aunque el sistema de archivos es el que 
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más hace referencia a este archivo, sus definiciones también se necesitan en varios lugares del kemel y del 
administrador de memoria. 

El resto de los archivos de include/no se utiliza tan ampliamente como los que ya mencionamos. 
Stdlib.h (línea 1000) define tipos, macros y prototipos de funciones que probablemente se requerirán en la 
compilación de todos los programas en C, con excepción de los más sencillos. Esta cabecera es una de las 
que se utilizan con mayor frecuencia al compilar programas de usuario, aunque dentro de la fuente del 
sistema MINIX sólo hacen referencia a ella unos cuantos archivos del kemel. 

Como veremos cuando exam in emos la capa de tareas en el capítulo 3, la interfaz con la consola y las 
ter mi n a les de un sistema operativo es compleja porque muchos tipos diferentes de hardware deben 
interactuar con el sistema operativo y los programas de usuario de una forma estandarizada. La cabecera 
termios.h (línea 1100) define constantes, macros y protototipos de funciones que se emplean para 
controlar dispositivos de E/S tipo terminal. La estructura más importante es termios, que contiene 
banderas para indicar diversos modos de operación, variables para fijar las velocidades de transmisión de 
entrada y salida, y un arreglo para contener caracteres especiales, como los caracteres INTR y KILL. POS 
exige esta estructura, lo mismo que muchas de las macros y prototipos de funciones definidos en este 
archivo. 

Sin embargo, a pesar de que se pretende que el estándar POS abarque todo, no proporciona todo lo 
que podríamos querer, y la última parte del archivo, de la línea 1241 en adelante, provee extensiones de 
POSIX. Algunas de éstas tienen un valor obvio, como las extensiones para definir velocidades de 
transmisión de 57 600 baudios y superiores, y el apoyo para ventanas en la pantalla de la terminal. El 
estándar OSiX no prohíbe las extensiones, ya que ningún estándar razonable puede abarcar todo lo habido 
y por haber; pero al escribir un programa en el entorno MINIX que pretenda ser portátil a otros entornos, 
se requiere cierta cautela para evitar el uso de definiciones especificas para MINIX. Esto es fácil. En este 
archivo y otros que definen extensiones específicas para MINIX, el empleo de las extensiones está 
controlado por una instrucción 

#ifdef MINIX 

Si no se ha definido MINIX, el compilador ni siquiera verá las extensiones para MINIX. 

El último archivo que veremos en inelude/ es a. outh (línea 1400), una cabecera que define el 
formato de los archivos en los que se almacenan programas ejecutables en disco, incluida la estructura de 
cabecera que sirve para iniciar la ejecución de un archivo, y la estructura de tabla de símbolos producida 
por el compilador. Sólo el sistema de archivos hace referencia a esta cabecera. 

Pasemos ahora al subdirectorio include/sysi. Como se muestra en la Fig. 2-28, todas las cabeceras 
maestras de las partes principales del sistema MINIX incluyen sys/types. h (línea 1600) inmediatamente 
después de leer ansi.h. Esta cabecera define muchos tipos de datos empleados por MINIX. Los errores que 
podrían surgir si no se entiende bien cuáles tipos de datos fundamentales se usan en una situación en 
particular pueden evitarse si se utilizan las definiciones provistas en esta cabecera. La Fig. 2-29 muestra la 
forma en que difieren los tamaños, en bits, de unos cuantos tipos definidos en este archivo cuando se 
compilan para procesadores de 16 o de 32 bits. Observe que Sos los nombres de tipo terminan con “_t”. 
Esto no es sólo una convención, sino un requisito del estándar POSIX. Éste es un ejemplo de sufijo 
reservado, y no debe usarse como sufijo de ningún nombre que no sea un nombre de tipo. 



106 


PROCESOS 


CAP.2 



Figura 2-29. El tamaño, en bits, de algunos tipos en sistemas de 16 y de 32 bits. 


Aunque no se utiliza tan ampliamente como para que se incluya en las cabeceras de todas las 
secciones, sysliocti. h (línea 1800) define muchas macros empleadas para operaciones de control de 
dispositivos. Esta cabecera también contiene el prototipo de la llamada al sistema IOCTL. En muchos 
casos, los programadores no invocan directamente esta llamada, ya que las funciones definidas por rosix 
cuyos prototipos están en includeltermíos.h han sustituido muchos usos de la antigua función de biblioteca 
ioctl para manejar terminales, consolas y dispositivos similares; no obstante, sigue siendo necesaria. De 
hecho, las funciones POSIX para controlar dispositivos de ter mi nal son convertidas en llamadas IOCTL 
por la biblioteca. Además, hay un número cada vez mayor de dispositivos, todos los cuales necesitan 
diversos tipos de control, que pueden conectarse a un sistema de computadora moderno. Por ejemplo, 
cerca del final de este archivo se definen varios códigos de operación que comienzan con DSPIO y que 
sirven para controlar un procesador de señales digitales. De hecho, la diferencia principal entre MINIX tal 
como se describe en este libro y otras versiones es que para los fines del libro describimos un MINIX con 
relativamente pocos dispositivos de entrada/salida. Es posible agregar muchos más, como interfaces de 
red, unidades de CD-ROM y taijetas de sonido; los códigos de control para todos éstos se definen como 
macros en este archivo. 

Varios otros archivos de este directorio se utilizan ampliamente en el sistema MINIX. El archivo 
sys/sigcontext.h (línea 2000) define estructuras que se usan para preservar y restablecer la operación 
normal del sistema antes y después de la ejecución de una rutina de manejo de señales y se usa tanto en el 
kemel como en el administrador de memoria. MINIX ofrece apoyo para rastrear ejecutables y analizar 
vaciados de núcleo con un programa depurador, y sys/ptrace. h (línea 2200) define las diversas 
operaciones posibles con la llamada al sistema PTRACE. Sys/stat.h (línea 2300) define la estructura que 
vimos en la Fig. 1-12 y que es devuelta por las llamadas al sistema STAT y FSTAT, así como los 
prototipos de las funciones stat y fstat y otras fruiciones que sirven para manipular las propiedades de los 
archivos. Se hace referencia a esta cabecera en varias partes del sistema de archivos y del administrador de 
memoria. 

Los dos últimos archivos que mencionaremos en esta sección no tienen tantas referencias como los 
que vimos antes. Sys/dir.h (línea 2400) define la estructura de una entrada de directorio en MINIX. Sólo 
se hace referencia directa a él una vez, pero esta referencia lo incluye en otra cabecera que se utiliza 
ampliamente en el sistema de archivos. Sys/dir.h es importante porque, entre otras cosas, indica cuántos 
caracteres puede contener un nombre de archivo. Por último, la cabecera sys/wait.h (línea 2500) define 
macros utilizadas por las llamadas al sistema WA1T y WAITPID, que se implementan en el administrador 
de memoria. 
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2.6.3 Los archivos de cabecera de MINIX 

Los subdirectorios include/minixi e include/ibm./ contienen archivos de cabecera específicos para MINIX. 
Los archivos de include/minixlse necesitan para implementar MINIX en cualquier plataforma, aunque hay 
definiciones alternativas, específicas para una plataforma, dentro de algunos de ellos. Los archivos de 
include/ibm/ definen estructuras y macros específicas para MINIX tal como se implementa en máquinas 
tipo IBM. 

Comenzaremos con el directorio mmix En la sección anterior señalamos que config.h (línea 2600) 
se incluye en las cabeceras maestras de todas las partes del sistema MINIX, y por tanto es el primer 
archivo que el compilador procesa realmente. En muchas ocasiones en las que diferencias ene! hardware o 
en la forma en que se pretende que se use el sistema operativo requieren cambios a la configuración de 
MINIX, lo único que se necesita es editar este archivo y recompilar el sistema. Todos los parámetros 
ajustables por el usuario están en la primera parte del archivo. El primero de ellos es el parámetro 
MACHINE, que puede adoptar valores como IBMPC, SUN 4, MACINTOSH u otros, dependiendo del 
tipo de máquina para la cual se está compilando MINIX. La mayor parte del código de MINIX es 
independiente del tipo de máquina, pero un sistema operativo siempre tiene algo de código dependiente 
del sistema. En los pocos lugares de este libro en los que habla remos de código que se escribe de forma 
diferente para distintos sistemas usaremos como ejemplo código escrito para máquinas tipo IBM PC con 
chips procesadores avanzados (80386, 80486, Pentium, Pentium Pro) que usan palabras de 32 bits. Nos 
referiremos a todos éstos como procesa dores Intel de 32 bits. También puede compilarse MINIX para 
IBM PC más viejas con tamaño de palabra de 16 bits, y las partes de MINIX que dependen de la máquina 
deben codificarse de forma diferente para estas máquinas. En una PC, el compilador mismo determina el 
tipo de máquina para la cual se compilará MINIX. El compilador estándar de MINIX para PC es el del 
Amsterdam Compiler Kit (ACK), el cual se identifica a sí mismo definiendo, además de la macro 

_STDC_, la macro _ACK_. Este compilador también define una macro EMWSIZE que es el 

tamaño de palabra (en bytes) de su máquina objetivo. En la línea 2626 se asigna el valor de EM WSIZE 
a una macro llamada WORDSIZE. Más adelante en el archivo y en diversos lugares de los demás 
archivos fuente de MINIX se utilizan estas definiciones. Por ejemplo, las líneas 2647 a 2650 comienzan 
con la prueba 

#if (MACHINE == IBM PC &&_WORD_SIZE = 4) 

y definen un tamaño para el caché de buffers del sistema de archivos en los sistemas de 32 bits. 

Otras definiciones de config.h permiten personalizar otras necesidades de una instalación en 
particular. Por ejemplo, hay una sección que permite incluir diversos tipos de controladores de 
dispositivos cuando se compila el kemel de MINIX. Es probable que ésta sea la parte del código fuente de 
MINIX que se edite con mayor frecuencia. Esta sección comienza con: 

#define ENABLE NETWORKING O 
#define ENABLE AT WINI 1 
#define ENABLE BIOS WINI O 

Si cambiamos el O de la primera línea a 1 podremos compilar un kemel de MINIX para una máquina 
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que necesita apoyo de red. Si definimos ENABLEATWINI como O y ENABLE BIOS WINI como 1, 
podemos eliminar el código de controlador de disco duro tipo AT (es decir, IDE) y usare/ PC BIOS para el 
apoyo de disco duro. 

El siguiente archivo es const.h (línea 2900) que ilustra otro uso común de los archivos de cabecera. 
Aquí encontramos diversas definiciones de constantes que con toda seguridad no se modificarán al 
compilar un nuevo kemel pero que se usan en varios lugares. Al definirlas aquí se ayuda a prevenir errores 
que podrían ser difíciles de rastrear si se efectuaran definiciones inconsistentes en múltiples puntos. Hay 
otros archivos llamados const.h en el árbol fuente de M1NIX, pero su uso es más limitado. Las 
definiciones que se usan sólo en el kemel se incluyen en src/kemel/const.h. Las definiciones que se usan 
sólo en el sistema de archivos se incluyen en src/ fs/const.h. El administrador de memoria usa 
src/mm/const.h para sus definiciones locales. Sólo las definiciones que se usan en más de una parte del 
sistema MINIX se incluyen en include/minixlconst.h. 

Unas cuantas de las definiciones de const.h merecen mención especial. EXTERN se define como 
una macro que se expande para crear extern (línea 2906). Las variables globales que se declaran en 
archivos de cabecera y se incluyen en dos o más archivos se declaran EXTERN, como en 

EXTERN mt who; 

Si la variable se declarara simplemente como 
int who; 

y se incluyera en dos o más archivos, algunos enlazadores protestarían por haberse definido una variable 
más de una vez. Además, el manual de referencia de C (Kemighan y Ritchie, 1988) prohíbe 
explícitamente esta construcción. 

A fin de evitar este problema, es necesario escribir la declaración de la siguiente manera: 
extern in who; 

en todos los lugares menos uno. El empleo de EXTERN previene este problema porque se hace que se 
expanda a extern en todos los lugares en que se incluye const.h, excepto después de una redefinición 
explícita de EXTERN como la cadena nula. Esto se hace en cada una de las partes de MINIX colocando 
las definiciones globales en un archivo especial llamado glo.h; por ejemplo, src/ kcrncl/glo.h, que se 
incluye indirectamente en todas las compilaciones. Dentro de cada glo.h hay una secuencia 

#ifdef TABLE 

#undef EXTERN #define EXTERN #endif 

y en los archivos table.c de cada parte de MINIX hay una línea #define TABLE 

antes de la sección #include. Así, cuando los archivos de cabecera se incluyen y expanden 
como parte de la compilación de table. c, extern no se inserta en ningún lugar (porque EXTERN se 
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define como la cadena nula dentro de table.c) y sólo se reserva memoria para las variables globales en un 
lugar, en el archivo objeto table.o. 

Si usted no tiene experiencia programando en C y no entiende muy bien lo que está sucediendo 
aquí, no se preocupe; los detalles no son realmente importantes. La inclusión múltiple de archivos de 
cabecera puede causar problemas a algunos enlazadores porque puede dar lugar a múltiples declaraciones 
de las variables incluidas. El asunto de EXTERN no es más que una forma de hacer a MINIX más portátil, 
de modo que pueda enlazarse en máquinas cuyos enlazadores no aceptan variables con múltiples 
definiciones. 

PRIVATE se define como sinónimo de static. Los procedimientos y datos a los que no se hace 
referencia fúera de los archivos en los que se declaran siempre se declaran como PRIVA TE para evitar 
que sus nombres sean visibles afúera del archivo en el que se declaran. Por regla general, todas las 
variables y procedimientos deben declararse con alcance local hasta donde sea posible. PUBLIC se define 
como la cadena nula. Así, la declaración 

PUBLIC void free_zone(Dev_t dey, zonet numb) 
sale del preprocesador de C como 
void ffee_zone(Dev_t dey, zone t numb) 

que, según las reglas de alcance de C, implica que el nombre free zone se exporta del archivo y puede 
usarse en otros archivos. PRIVATE y PUBLIC no son necesarios, pero son intentos por contrarrestar el 
daño causado por las reglas de alcance de C (la acción por omisión es que los nombres se exportan afuera 
del archivo; debería ser exactamente lo contrario). 

El resto de const. h define constantes numéricas que se usan en todo el sistema. Una sección de 
const.h está dedicada a las definiciones dependientes de la máquina o de la configuración. Por ejemplo, en 
todo el código fuente la unidad básica de tamaño de memoria es el click. El tamaño de un click depende 
de la arquitectura del procesador, y en las líneas 2957 a 2965 se definen alternativas para arquitecturas 
Intel, Motorola 68000 y Sun SPARC. Este archivo también contiene las macros MAX y MIN que nos 
permiten escribir 

z = MAX(x, y); 

para asignar el mayor de x y y a z. 

Type.h (línea 3100) es otro archivo que se incluye en todas las compilaciones por medio de las 
cabeceras maestras; contiene varias definiciones de tipos clave, junto con valores numéricos relacionados. 
La definición más importante de este archivo es message en las líneas 3135 a 3146. Aunque podríamos 
haber definido message como un arreglo con cierto número de bytes, es mejor desde el punto de vista de 
la práctica de programación hacer que sea una estructura que contiene una unión de los diversos tipos de 
mensajes posibles. Se definen sE/S formatos de mensaje, de Nzess l a mess_6. Un mensaje es una 
estructura que contiene un campo msource, para indicar quién envió el mensaje, un campo ,n_lype, para 
indicar qué tipo de mensaje es (p. ej., GET T1ME a la tarea del reloj) y los campos de datos. Los sE/S 
tipos de mensajes se muestran en la Fig. 2-30. En la figura los tipos de mensajes primero y segundo 
parecen idénticos, iguales que el cuarto y el sexto. Esto es cierto cuando MINIX se implementa en una 
CPU Intel con tamaño de palabra de 32 



110 


PROCESOS 


CAP.2 


bits, pero no sería el caso en una máquina en la que los mt, long y apuntadores tienen diferentes tamaños. 
La definición de sE/S formatos distintos facilita la recompilación para una arquitectura distinta. 
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Figura 2-30. Los seis tipos de mensajes empleados en MIN1X Los tamaños de los elementos 
de los mensajes varían dependiendo de la arquitectura de la máquina; este diagrama ilustra 
los tamaños en una máquina con apuntadores de 32 bits, como la Pentium (Pro). 


Si es necesario enviar un mensaje que contiene, digamos, tres enteros y tres apuntadores (o tres enteros y 
dos apuntadores), el formato que debe usarse es el primero de la Fig. 2-30. Lo mismo se 
aplica a los demás formatos. ¿Cómo asignamos un valor al primer entero en el primer formato? 
Supongamos que el mensaje se llama x. Entonces, x.mu se refiere a la porción e 
unión de la estructura message. Si queremos referimos a la primera de las sE/S alternativas de la 
unión, 
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usamos x.mu.mml. Por último, para acceder al primer entero de esta struct escribimos 
x.mu.mml.mlil. Esto es un poco torpe, y es por ello que se definen nombres de campos más cortos 
después de la definición de message misma. Así, podemos usar x.mlil en lugar de x.m u.m ml.mlil. 
Todos los nombres cortos tienen la forma de la letra m, el número de formato, un subraya, una o dos letras 
que indican si el campo es un entero (i), apuntador (p), long (1), carácter (c), arreglo de caracteres (ca) o 
fúnción (f), y un número de secuencia para distinguir múltiples ejemplares del mismo tipo dentro de un 
mensaje. 

Como acotación, al hablar de los formatos de mensaje es pertinente señalar que un sistema 
operativo y su compilador a menudo tienen un “acuerdo” en lo tocante a cosas como la organización de 
las estructuras, y esto puede facilitar las cosas para el implementador. En MINIX los campos mt de los 
mensajes a veces se usan para contener tipos de datos unsigned. En algunos casos esto podría causar un 
desbordamiento, pero el código se escribió aprovechando el conocimiento de que el compilador de MINIX 
copia los tipos unsigned en ints y viceversa sin alterar los datos ni generar código para detectar un 
desbordamiento. Un enfoque más minucioso habría sido sustituir cada uno de los campos mt por una 
unión de un mt y un unsigned. Lo mismo aplica a los campos long de los mensajes; algunos de ellos 
pueden usarse para pasar datos unsigned long. ¿Estamos haciendo trampa aquí? Algunos dirían que sí, 
pero si queremos trasladar MINIX a una nueva plataforma, es evidente que el formato exacto de los 
mensajes es algo en lo que debemos poner mucha atención, y ahora estamos advertidos de que el 
comportamiento del compilador es otro factor al que debemos prestar atención. 

Elay otro archivo en include/minix/ que se utiliza umversalmente mediante la inclusión en las 
cabeceras maestras. Se trata de syslib.h (línea 3300), que contiene prototipos de fúnciones de biblioteca de 
C que se invocan desde el interior del sistema operativo para acceder a otros servicios del sistema 
operativo. Las bibliotecas de C no se explican con detalle en este texto, pero muchas de ellas son estándar 
y están disponibles para cualquier compilador de C. Sin embargo, las funciones de C a las que hace 
referencia syslib.h son, por supuesto, específicas para MINIX y si se va a trasladar MINIX a un nuevo 
sistema con un compilador distinto es necesario trasladar también estas funciones de biblioteca. Por 
suerte, esto no es difícil, ya que estas fúnciones simple mente extraen el parámetro de la invocación de la 
fúnción y los insertan en una estructura de mensaje, luego envían el mensaje y extraen los resultados del 
mensaje de respuesta. Muchas de estas funciones de biblioteca se definen en una docena de líneas de 
código en C o menos. 

Cuando un proceso necesita ejecutar una llamada al sistema de MINIX, envía un mensaje al 
administrador de memoria (MM) o el sistema de archivos (FS). Cada mensaje contiene el número de la 
llamada deseada. Estos números se definen en el siguiente archivo, callnrh (línea 3400). 

El archivo com.h (línea 3500) contiene casi exclusivamente definiciones comunes empleadas en 
mensajes del MM y el PS a las tareas de E/S. También se definen los números de las tareas. Para 
distinguirlos de los números de proceso, los números de tarea son negativos. Esta cabecera también define 
los tipos de mensajes (códigos de fúnción) que se pueden enviar a cada tarea. Por ejemplo, la tarea del 
reloj acepta los códigos SET ALARM (que sirve para establecer un cronómetro), CLOCK TICK (cuando 
ha ocurrido una interrupción de reloj), GET TJME (para solicitar el tiempo real) y SET TIME (para 
establecer la hora del día vigente). El valor REAL TIME es el tipo de mensaje para la respuesta a la 
solicitud GET TIME. 
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Por último, include/minixi contiene varias cabeceras más especializadas. Entre éstas se encuentran 
boot.h (línea 3700), que usan tanto el kemel como el sistema de archivos para definir dispositivos y 
acceder a parámetros pasados al sistema por el programa boot. Otro ejemplo es keymap.h (línea 3800), 
que define 1 estructuras empleadas para implementar organizaciones de teclado especializadas con los 
conjuntos de caracteres necesarios para diferentes idiomas. Los programas que generan y cargan estas 
tablas también lo necesitan. Algunos archivos de este directorio, como partition.h (línea 4000) sólo son 
utilizados por el kemel, y no por el sistema de archivos ni el administrador de memoria. En una 
implementación con apoyo para dispositivos de E/S adicionales hay más archivos de cabecera como éste, 
apoyando otros dispositivos. Su colocación en este directorio requiere una explicación. Idealmente, todos 
los procesos de usuario accederían a los dispositivos sólo a través del sistema operativo, y los archivos 
como éste se colocarían en src/kemel/. Sin embargo, las realidades de la administración de sistemas 
exigen que haya algunos comandos de usuario que accedan a estructuras en el nivel de sistema, como los 
comandos que crean particiones de disco. Es para apoyar tales programas de rutinas de utilidad que estos 
archivos de cabecera especializados se colocan en el árbol de directorios inelude/. 

El último directorio de cabeceras especializadas que consideraremos, include/ibm/, contiene dos 
archivos que proporcionan definiciones relacionadas con la familia de computadoras IBM PC. Uno de 
ellos es diskparm.h, utilizado por la tarea del disco flexible. Aunque esta tarea se incluye en la versión 
estándar de MINIX, su código fuente no se verá con detalle en este texto, ya que es muy similar a la tarea 
del disco duro. El otro archivo de este directorio es partition.h (línea 4100), que define las tablas de 
partición de disco y las constantes relacionadas que se usan en los sistemas compatibles con IBM. Éstas se 
colocan aquí para facilitar el traslado de MINIX a otra plataforma de hardware. Si se usa un hardware 
diferente, tendría que reemplazarse include/ibm/ partition.h, probablemente por un partition.h en algún 
otro directorio de nombre apropiado, pero la estructura definida en el archivo include/minixipartition. h es 
intema de MINIX y debe permanecer inalterada en un MINIX albergado en una plataforma de hardware 
distinta. 


2.6.4 Estructuras de datos de procesos y archivos de cabecera 

Metámonos ahora de lleno en el código de src/kemel/ y veamos qué aspecto tiene. En las dos secciones 
anteriores estructuramos nuestra explicación alrededor de un extracto de una cabecera maestra 
representativa; examinaremos primero la verdadera cabecera maestra del kemel, kemel.h (línea 4200). Lo 
primero que se hace es definir tres macros. La primera, POSIX SOURCE es una macro de prueba de 
capacidades definida por el estándar POSIX mismo. Todas las macros de este tipo deben comenzar con el 
carácter de subraya, El efecto de definir la macro POSJX SOURCE es asegurar que todos los 
símbolos requeridos por el estándar y todos los que se permiten explícitamente, pero que no son 
obligatorios, estén visibles, al tiempo que se ocultan todos los demás símbolos que son extensiones 
no oficiales de rosix. Ya mencionamos las dos definiciones que siguen: la macro MINIX somete 
el efecto de POSIXSOURCE para extensiones definidas por MINIX, y SYSTEM 

se puede probar siempre que sea importante hacer algo de forma diferente al 

compilar código del sistema, en contraposición a código de usuario, como cambiar el 
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signo de los códigos de error. A continuación, kemel.h incluye otros archivos de cabecera de inelude/ y 
sus subdirectorios include/sys/ e include/minixi, incluidos todos aquellos a los que se hace referencia en la 
Fig. 2-28. Ya hablamos de todos estos archivos en las dos secciones anteriores. Por último, se incluyen 
cuatro cabeceras más del directorio local, src/kernel/. 

Éste es un buen lugar para explicar, a quienes no tienen experiencia con el lenguaje C, la forma 
como se citan los nombres de archivo en una instrucción #include. Todo compilador de C tiene un 
directorio por omisión en el cual busca los archivos de inclusión. Por lo regular, éste es /usr/include/, 
como lo es en un sistema MINIX estándar. Si el nombre del archivo por incluir se encierra en paréntesis 
angulares (“< ... >“) el compilador busca el archivo en el directorio de inclusión por omisión o en un 
subdirectorio especificado de ese directorio. Si el nombre se encierra entre comillas ordinarias el 

archivo se busca primero en el directorio actual (o un subdirectorio especificado) y luego, si no se 
encuentra ahí, en el directorio por omisión. 

Kemel.h hace posible garantizar que todos los archivos fuente compartan un gran número de 
definiciones importantes escribiendo la línea 

#include “kemel.h” 

en cada uno de los otros archivos fuente del kemel. Puesto que a veces es importante el orden de inclusión 
de los archivos de cabecera, kemel.h también se asegura de que este ordenamiento se efectúe 
correctamente, de una vez por todas. Esto lleva a un nivel más alto la técnica de “hazlo bien una vez y 
luego olvídate de los detalles” encamada en el concepto de archivo de cabecera. Hay cabeceras maestras 
similares en los directorios fuente del sistema de archivos y del administrador de memoria. 

Examinemos ahora los cuatro archivos de cabecera locales incluidos en kemel h. Así como 
tenemos archivos const.h y lype.h en el directorio de cabeceras comunes include/minixi, también tenemos 
archivos const.h y type.h en el directorio fúente del kemel, src/kernel/. Los archivos de include/minixi se 
colocan ahí porque muchas partes del sistema los necesitan, incluidos programas que se ejecutan bajo el 
control del sistema. Los archivos de src/kernel/ proveen definiciones que sólo se necesitan para compilar 
el kemel. Los directorios fuente del PS y el MM también contienen archivos const.h y type.h para definir 
constantes y tipos que sólo se necesitan en esas partes del sistema. Los otros dos archivos incluidos en la 
cabecera maestra, proto.h y glo.h, no tienen contrapartes en los directorios include/principales, pero 
habremos de ver que también tienen contra- partes que se usan para compilar el sistema de archivos y el 
administrador de memoria. 

Const. h (línea 4300) contiene varios valores dependientes de la máquina, es decir, valores que 
aplican a los chips de CPU Intel, pero que probablemente son diferentes cuando MIND( se compila en 
hardware distinto. Estos valores están delimitados por las instrucciones 

#if(CHIP ==INTEL) 

y 

#endif 

(líneas 4302 a 4396). 
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Al compilar MINIX para uno de los chips Intel se definen las macros CF/IP e iNTEL y se hacen 
iguales en include/minix/config.h (línea 2768); con ello se compila el código dependiente de la máquina. 
Cuando MINIX se trasladó a un sistema basado en el Motorola 68000, la gente que realizó el traslado 
agregó secciones de código delimitadas por 

#if (CHIP==M68000) 

y 

#endif 

e hizo los cambios apropiados en include/minixlconfig.h para que fuera efectiva una línea que decía 
#define CHIP M68000 

De este modo, MINIX puede manejar constantes y código que son específicos para un sistema. Esta 
construcción no ayuda mucho que digamos a la comprensibilidad, así que debe usarse lo menos posible. 
De hecho, en aras de tal comprensibilidad, hemos eliminado muchas secciones de código dependiente de 
la máquina para el 68000 y otros procesadores de la versión del código impresa en este texto. El código 
distribuido en el CD-ROM y por Internet conserva el código para otras plataformas. 

Unas cuantas de las definiciones de const.h merecen mención especial. Algunas de ellas son 
dependientes de la máquina, como los vectores de interrupción importantes y los valores de campos 
empleados para restablecer el chip controlador de interrupciones después de cada interrupción. Cada tarea 
dentro del kemel tiene su propia pila, pero durante el manejo de interrupciones se usa una pila especial de 
tamaño K STACK. BYTES, definida aquí en la línea 4304. La definición también está en la sección 
dependiente de la máquina, pues una arquitectura distinta podría requerir más o menos espacio de pila. 

Otras definiciones son independientes de la máquina, pero muchas partes del código del kemel las 
necesitan. Por ejemplo, el planificador de MINIX tiene NQ (3) colas de prioridad, llama das TASK Q 
(máxima prioridad), SERVER Q (prioridad media) y USER Q (prioridad más baja). Se usan estos 
nombres para hacer más comprensible el código fuente, pero los valores numéricos definidos por estas 
macros son lo que en realidad se compila en el código ejecutable. Por último, la última línea de const.h 
define printf como una macro cuya evaluación producirá printk. Esto permite al kemel exhibir mensajes, 
como los de error, en la consola usando un procedimiento definido dentro del kemel. Así se pasa por alto 
el mecanismo usual, que requiere transferir mensajes del kemel al sistema de archivos y luego del sistema 
de archivos a la tarea de impresora. Durante una falla del sistema esto podría no fúncionar. Veremos 
llamadas a printf, alias printk, en un procedimiento del kemel llamado panic que, como tal vez habrá 
imaginado, se invoca cuando se detectan errores fatales. 

El archivo type. h (línea 4500) define varios prototipos y estructuras que se emplean en cualquier 
implementación de MINIX. La estructura tasktab define la estructura de un elemento del arreglo tasktab y 
la estructura memory (líneas 4513 a 4516) define las dos cantidades que especifican de manera única un 
área de la memoria. Éste es un buen lugar para mencionar algunos conceptos 
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que se usan al referirse a la memoria. Un click es la unidad básica de medición de la memoria; en MiN 1 
para procesadores Intel un click es 256 bytes. La memoria se mide como physclicks, que el kemel puede 
usar para acceder a cualquier elemento de memoria en cualquier lugar del sistema, o como virclicks, 
utilizados por otros procesos distintos del kemel. Una referencia a memoria vir clicks siempre es relativa 
a la base de un segmento de memoria asignado a un proceso en particular, y el kemel a menudo tiene que 
hacer traducciones entre las dos mediciones. La necesidad de hacer esto se compensa con el hecho de que 
un proceso puede expresar todas sus referencias a la memoria en vir clicks. Podríamos suponer que sería 
factible usar la misma unidad para especificar el tamaño de ambas clases de memoria, pero el uso de 
vir clicks para especificar el tamaño de una unidad de memoria asignada a un proceso tiene la ventaja de 
que en cada ocasión se verifica que no se acceda a ninguna posición de memoria fuera de la que se asignó 
específicamente al proceso actual. Ésta es una característica importante del modo protegido de los 
procesadores Intel modernos, como el Pentium y el Pentium Pro. Su ausencia en los primeros 
procesadores 8086 y 8088 causó algunos dolores de cabeza en el diseño de versiones anteriores de 
fSENIX. 

Type.h también contiene varias definiciones de tipos dependientes de la máquina, como portt, 
segmt y regt (líneas 4525 a 4527) empleados en los procesadores Intel para direccionar, 
respectivamente, puertos de E/S, segmentos de memoria y registros de la CPU. 

También las estructuras pueden ser dependientes de la máquina. En las líneas 4537 a 4558 se define 
la estructura stackframes, que establece la forma en que los registros de la máquina se guardan en la pila, 
para los procesadores Intel. Esta estructura es extremadamente importante; se usa para guardar y restaurar 
el estado interno de la CPU cada vez que un proceso pasa al estado “ejecutándose” o deja de estar en ese 
estado (Fig. 2-2). Al definirla en una forma que se puede leer o escribir eficientemente con código en 
lenguaje ensamblador se reduce el tiempo requerido para una conmutación de contexto. Segdesc s es otra 
estructura relacionada con la arquitectura de los procesadores Intel; forma parte del mecanismo de 
protección que impide a los procesos acceder a regiones de memoria afuera de las que les fueron 
asignadas. 

Con objeto de ilustrar las diferencias entre plataformas, se conservaron en este archivo unas cuantas 
definiciones para la fa mi lia de procesadores Motorola 68000. La familia de procesadores Intel incluye 
algunos modelos con registros de 16 bits y otros con registros de 32 bits, así que el tipo reg t básico es 
unsigned para la arquitectura Intel. Para los procesadores Motorola reg t se define como el tipo u32_t. 
Estos procesadores también necesitan una estructura stackffames (líneas 4583 a 4603), pero la 
organización es diferente, a fin de hacer que las operaciones en código de ensamblador que la usan sean lo 
más rápidas posible. La arquitectura Motorola no necesita los tipos port t ni segm t, ni la estructura 
segdesc s. Hay varias otras estructuras definidas para la arquitectura Motorola que no tienen contrapartes 
en Intel. 

El siguiente archivo, proto.h (línea 4700), es el archivo de cabecera más grande que veremos. Este 
archivo contiene prototipos de todas las funciones que deben conocerse afuera del archivo en el que se 
definen. Todos se escribieron usando la macro PROTOTYPE que mencionamos antes en 
esta misma sección, así que el kemel de MINIX se puede compilar ya sea con un compilador de 

C clásico (Kemighan & Ritchie), como el compilador de C de MINIX original, 

o un compilador moderno de ANSI Standard C, como el que forma parte de la distribución de 
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MINIX Versión 2. Varios de estos prototipos dependen del sistema, incluidos los manejadores de 
interrupciones y excepciones y las funciones escritas en lenguaje ensamblador. No se muestran los 
prototipos de funciones requeridas por controladores que no se mencionan en este texto. También se ha 
eliminado el código condicional para procesadores Motorola de éste y los demás archivos que veremos. 

La última de las cabeceras del kemel incluida en la cabecera maestra es glo.h (línea 5000). Aquí 
encontramos las variables globales del kemel. El propósito de la macro EXTERN se describió cuando 
hablamos de include/minix/const.h. Esta macro normalmente se expande para producir extern. Cabe 
señalar que muchas definiciones de glo.h van precedidas por esta macro. Se obliga a que EXTERN no esté 
definida cuando este archivo se incluye en table.c, donde se define la macro TABLE. La inclusión de 
glo.h en otros archivos fuente en C hace que las variables de table.c sean conocidas por los demás 
módulos del kemel. Heldhead y heid tail (líneas 5013 y 5014) son apuntadores a una cola de 
interrupciones pendientes. Proc_ptr (línea 5018) apunta a la entrada de la tabla de procesos 
correspondiente al proceso en curso. Cuando ocurre una llamada al sistema o una interrupción, este 
apuntador indica dónde deben almacenarse los registros y el estado del procesador. Sig_ procs (línea 
5021) cuenta el número de procesos que tienen señales pendientes que todavía no han sido enviadas al 
administrador de memoria para ser procesadas. Unos cuantos elementos de glo.h se definen con extern en 
lugar de EXTERN. Éstos incluyen sizes, un arreglo que es llenado por el monitor de arranque, la tabla de 
tareas, tasktab, y la pila de tareas, tstack. Las dos últimas son variables inicializadas, una característica 
del lenguaje C. El empleo de la macro EXTERN no es compatible con la inicialización al estilo C, puesto 
que una variable sólo puede inicializarse una vez. 

Cada tarea tiene su propia pila dentro de t stack. Durante el manejo de interrupciones, el kemel usa 
una pila aparte, pero ésta no se declara aquí, ya que a ella sólo accede la rutina de nivel de lenguaje 
ensamblador que se encarga del procesamiento de interrupciones, y no tiene que ser conocida 
globalmente. 

Hay otros dos archivos de cabecera del kemel que se utilizan ampliamente, aunque no tanto que 
merezcan incluirse en kemel/. h. El primero de éstos es proc.h (línea 5100), que define una entrada de 
tabla de procesos como un struct proc (líneas 5110 a 5148). Más adelante en el mismo archivo, se define 
la tabla de procesos misma como un arreglo de tales structs, proc + NR PROCS] (línea 5186). En el 
lenguaje C está permitida semejante reutilización de un nombre. La macro NR TASKS se define en 
include/minix/const.h (línea 2953) y NR PROCS se define en include/minix/config.h (línea 2639). Juntas, 
éstas dictan el tamaño de la tabla de procesos. NR PROCS puede ser modificada para crear un sistema 
capaz de manejar un número grande de usuarios. Dado que el acceso a la tabla de procesos es frecuente, y 
el cálculo de una dirección en un arreglo requiere operaciones de multiplicación lentas, se utiliza un 
arreglo de apuntadores a los elementos de la tabla de procesos, pproc addr (línea 5187), con objeto de 
lograr un acceso rápido. 

Cada entrada de la tabla tiene espacio para los registros del proceso, el apuntador a la pila, el 
estado, el mapa de memoria, el límite de la pila, el identificador del proceso, datos de contabilización, 
tiempo de alarma e información de mensajes. La primera parte de cada entrada de la tabla de procesos es 
una estructura stackframes. Un proceso se pone en ejecución cargando su apuntador 
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a la pila con la dirección de su entrada en la tabla de procesos y sacando todos los registros de CPU de 
esta estructura. 

Cuando un proceso no puede completar un SEND porque el destino no está esperando, el emisor se 
pone en una cola a la que apunta el campo p callerq del destino (línea 5137). De este modo, cuando el 
destino finalmente ejecuta un RECEIVE, es fácil encontrar todos los procesos que desean enviarle algo. El 
campo psendlink (línea 5138) sirve para enlazar los miembros de la cola. 

Cuando un proceso ejecuta RECEIVE y no hay mensajes esperándolo, se bloquea y el número del 
proceso del cual desea recibir algo se almacena en pgetfrom. La dirección del buffer de mensajes se 
almacena en pmessbuf. Los últimos tres campos de cada entrada de la tabla de procesos son p nextready, 
p_pending y p_pendcount (líneas 5143 a 5145). El primero de éstos se usa para enlazar los procesos en las 
colas del planificador, y el segundo es un mapa de bits que sirve para seguir la pista a las señales que 
todavía no se han pasado al administrador de memoria (porque éste no está esperando un mensaje). El 
último campo es un contador de esas señales. 

Los bits de bandera de p flags definen el estado de cada entrada de la tabla. Si cualquiera de los bits 
es 1, el proceso no puede ejecutarse. Las diversas banderas se definen y describen en las líneas 5154 a 
5160. Si la ranura no está en uso, se pone en 1 P SLOT FREE. Después de un FORK, se pone en 1 
NO MAP para evitar que el proceso hijo se ejecute antes de que se haya preparado su mapa de memoria, 
SENDING y RECE! VING indican que el proceso está bloqueado tratando de enviar o recibir un mensaje. 
PENDING y SJG PENDJNG indican que se han recibido señales, y P STOP sirve como apoyo para el 
rastreo durante la depuración. 

La macro proc addr (línea 5179) se incluye porque no es posible tener subíndices negativos en C. 
Lógicamente, el arreglo proc debería ir de —NR TASKS a +NRPROCS. Desafortunada mente, en C el 
arreglo debe comenzar en 0, así que proc se refiere a la tarea más negativa, y así. Para que sea más fácil 
calcular cuál ranura corresponde a cuál proceso, podemos escribir 

rp = procaddr(n); 

para asignar a rp la dirección de la ranura de proceso correspondiente al proceso n, sea positivo o 
negativo. 

Bill_ptr (línea 5191) apunta al proceso al que se le está cobrando por la CPU. Cuando un proceso de 
usuario invoca al sistema de archivos, y éste se está ejecutando, proc_ptr (en glo.h) apunta al proceso del 
sistema de archivos. Sin embargo, bill_ptr apunta al usuario que realizó la invocación, ya que el tiempo de 
CPU usado por el sistema de archivos se carga como tiempo de sistema al invocador. 

Los dos arreglos rdy head y rdy tail sirven para mantener las colas de planificación. Por ejemplo 
rdy hcad apunta al primer proceso de la cola de tareas. 

Otra cabecera que se incluye en varios archivos fúente distintos es protect.h (línea 5200). Casi todo 
lo que contiene este archivo tiene que ver con detalles de la arquitectura de los procesadores 
Intel que manejan el modo protegido (80286, 80386, 80486, Pentium y Pentium Pro). 
Una descripción detallada de estos chips rebasa el alcance de este libro. Baste decir que 
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contienen registros internos que apuntan a tablas de descriptores en la memoria. Las tablas de descriptores 
definen la forma como se usan los recursos del sistema e impiden a los procesos acceder a áreas de 
memoria asignadas a otros procesos. Además, la arquitectura del procesador contempla cuatro niveles de 
privilegio, de los cuales MINIX aprovecha tres. Éstos se definen simbólicamente en las líneas 5243 a 
5245. Las partes más centrales del kemel, las que se ejecutan durante las interrupciones y conmutan 
procesos, se ejecutan con INTRPRIVILEGE. No hay ninguna parte de la memoria ni ningún registro de 
la CPU a los que no pueda acceder un proceso con este nivel de privilegio. Las tareas se ejecutan en el 
nivel TASK PRIVILEGE, que les permite acceder a E/S pero no usar instrucciones que modifiquen 
registros especiales, como los que apuntan a las tablas de descriptores. Los servidores y los procesos de 
usuario se ejecutan en el nivel USER PRIVILEGE. Los procesos que se ejecutan en este nivel no pueden 
ejecutar ciertas instrucciones, por ejemplo las que acceden a puertos de E/S, modifican asignaciones de 
memoria o cambian los niveles de privilegio mismos. El concepto de nivel de privilegio debe ser conocido 
para quienes están familiarizados con la arquitectura de las CPU modernas, pero quienes aprendieron 
arquitectura de computadoras estudiando el lenguaje de ensamblador de los procesadores menos potentes 
tal vez no se hayan topado con tales restricciones. 

Hay varios otros archivos de cabecera en el directorio del kemel, pero sólo mencionaremos otros 
dos aquí. Primero está sconst.h (línea 5400), que contiene constantes utilizadas por el código de 
ensamblador. Todas éstas son desplazamientos dentro de la porción de estructura stackframes de una 
entrada de la tabla de procesos, expresados en una forma susceptible de ser utilizada por el ensamblador. 
Puesto que el código de ensamblador no es procesado por el compilador de C, es más sencillo tener tales 
definiciones en un archivo aparte. Además, puesto que todas estas definiciones dependen de la máquina, 
aislarlas aquí simplifica el proceso de trasladar MINIX a otro procesador que necesitará una versión 
distinta de sconsth. Cabe señalar que muchos desplazamientos se expresan como el valor anterior más W, 
que se hace igual al tamaño de palabra en la línea 5401. Esto permite usar el mismo archivo para compilar 
una versión de MINIX de 16 o de 32 bits. 

Aquí hay un problema potencial. Se supone que los archivos de cabecera nos permiten proveer un 
solo correo correcto de definiciones y luego utilizarlas en muchos lugares sin tener que volver a prestar 
mucha atención a los detalles. Obviamente, las definiciones duplicadas, como las de sconsth, violan ese 
principio. Desde luego, se trata de un caso especial, pero, como tal, requiere atención especial si se llega a 
modificar ya sea este archivo o proc.h, a fin de asegurar que los dos archivos sean consistentes. 

La última cabecera que mencionaremos aquí es assert.h (línea 5500. El estándar POSIX obliga a 
contar con una Junción assert, que puede servir para realizar una prueba en el momento de la ejecución y 
abortar un programa, exhibiendo un mensaje. De hecho, Posix exige que se proporcione una cabecera 
asserth en el directorio inelude/, y se proporciona una allí. Entonces, ¿por qué hay otra versión aquí? La 
razón es que cuando algo sale mal en un proceso de usuario, se puede confiar en que el sistema operativo 
proporcionará servicios tales como exhibir un mensaje en la consola. Pero si algo falla en el kemel mismo, 
no puede contarse con los recursos normales del sistema. Por ello, el kemel provee sus propias rutinas 
para manejar assert y exhibir mensajes, con independencia de las versiones de la biblioteca normal del 
sistema. 
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Hay unos cuantos archivos de cabecera en kemel/ que no hemos visto todavía. Éstos apoyan las 
tareas de E/S y se describirán en el siguiente capítulo donde sean pertinentes. Antes de pasar al código 
ejecutable, empero, examinemos table.c (línea 5600) cuyo archivo objeto compilado contendrá todas las 
estructuras de datos del kemel. Ya hemos visto la definición de muchas de estas estructuras de datos, en 
glo.h y proc.h. En la línea 5625 se define la macro TABLE, inmediatamente antes de las instrucciones 
#include. Como ya se explicó, esta definición hace que EXTERN quede definida como la cadena nula, y 
que se asigne espacio de almacenamiento a todas las declaraciones de datos precedidas por EXTERN. 
Además de las estructuras de glo.h y proc.h, también se asigna aquí memoria para unas cuantas variables 
globales utilizadas por la tarea de terminal, definidas en tty.h. 

Además de las variables declaradas en archivos de cabecera, hay otros dos lugares donde se asigna 
memoria para datos globales. Algunas definiciones se realizan directamente en table.c. En las líneas 5639 
a 5674 se asigna espacio de pila a cada tarea. Para cada tarea opcional, se usa la macro ENABLEXXX 
correspondiente (definida en el archivo include/minix./confi g. h) para calcular el tamaño de la pila. Así, 
no se asigna espacio a una tarea que no está habilitada. Después de esto, se usan las diversas macros 
ENABLE XXX para determinar si cada tarea opcional se representará o no en ci arreglo tasktab, 
compuesto por estructuras tasktab, según se declaró antes en src/ kemellzype.h (líneas 5699 a 5731). Hay 
un elemento para cada proceso que se pone en marcha durante la inicialización del sistema, sea tarea, 
servidor o proceso de usuario (o sea, mit). El índice del arreglo establece implícitamente una 
correspondencia entre los números de tarea y los procedimientos de arranque asociados. Tasktab también 
especifica el espacio de pila requerido para cada proceso y provee una cadena de identificación para cada 
uno. Tasktab se colocó aquí y no en un archivo de cabecera porque el truco con EXTERN que se utilizó 
para evitar múltiples declaraciones no funciona con las variables inicializadas; es decir, no podemos 
escribir 

extern int x = 3; 

en ningún lado. Las definiciones anteriores de tamaño de pila también permiten el reparto de espacio de 
pila a todas las tareas en la línea 5734. 

A pesar del intento por aislar toda la información de configuración ajustable por el usuario en 
include/minixlconflg.h, puede cometerse un error al igualar el tamaño del arreglo tasktab con 
NR TASKS. Al final de table. c se realiza una prueba para detectar este error, usando un pequeño truco. 
Se declara aquí el arreglo ficticio dummytasktab de modo tal que su tamaño sea imposible y dé pie a un 
error de compilador si se cometió un error. Puesto que el arreglo ficticio se declara extern, no se le asigna 
espacio aquí (ni en ningún otro lado). Puesto que en ningún lugar del código se hace referencia a este 
arreglo, el compilador no objetará. 

El otro lugar donde se asigna almacenamiento global es al final del archivo en lenguaje 
ensamblador mpx386. s (línea 6483). Esta asignación, en la etiqueta sizes, 
coloca un número mágico (para identificar un kemel de MINIX válido) justo al principio del 
segmento de datos del kemel. Se asigna espacio adicional aquí con la seudoinstrucción .space. Al reservar 
memoria de esta manera, el programa en lenguaje ensamblador obliga a colocar físicamente el 
arreglo sizes al principio del segmento de datos del kemel, y esto facilita la programación de boot de 
modo tal que coloque los datos en el lugar correcto. El monitor de arranque lee el número mágico y, si es 
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correcto, lo sobreescribe para inicializar el arreglo sizes con los tamaños de las diferentes partes del 
sistema MINIX. El kemel utiliza estos datos durante la inicialización. En el momento del arranque, el 
kemel considera ésta como un área de datos inicializada. Sin embargo, los datos que el kemel finalmente 
encuentra aquí no están disponibles en el momento de la compilación. Estos datos son introducidos por el 
monitor de arranque justo antes de iniciarse el kemel. Todo esto es un poco inusual, pues normalmente no 
es necesario escribir programas que conozcan la estructura intema de otros programas. Sin embargo, el 
periodo después de que se enciende la máquina pero antes de que el sistema operativo esté funcionando es 
definitivamente inusual, y requiere técnicas poco usuales. 


2.6.5 Autoarranque de MINIX 

Ya casi es el momento de comenzar a exam in ar el código ejecutable, pero antes de hacerlo es conveniente 
dedicar un poco de tiempo a entender la forma como MINIX se carga en la memoria. Desde luego, 
MINIX se carga de un disco. La Fig. 2-31 muestra la organización de los disquetes y de los discos duros 
con particiones. 




Figura 2-31. Estructuras de disco utilizadas para autoarTanquc. (a) Disco sin particiones. El 
primer sector es el bloque de arranque, (b) Disco con particiones. El primer sector es el 
registro de arranque maestro. 
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Cuando se inicia el sistema, el hardware (en realidad, un programa en ROM) lee el primer sector 
del disco de arranque y ejecuta el código que encuentra ahí. En un disquete de MINIX sin particiones, el 
primer sector es un bloque de arranque que carga el programa de arranque (boot), como se aprecia en la 
Hg. 2-31 (a). Los discos duros tienen particiones, y el programa que está en el primer sector lee la tabla de 
particiones, que también está en el primer sector, y carga y ejecuta el primer sector de la partición activa, 
como se muestra en la Fig. 2-3 l(b). (Normalmente sólo una partición está marcada como activa). Una 
partición MINIX tiene la misma estructura que un disquete MINIX sin particiones, con un bloque de 
arranque que carga el programa de arranque. 

La situación real puede ser un poco más complicada que lo que sugiere la figura, porque una 
partición puede contener subparticiones. En tal caso el primer sector de la partición es otro registro de 
arranque maestro que contiene la tabla de particiones para las subparticiones. No obstante, tarde o 
temprano se transferirá el control a un sector de arranque, el primer sector de un dispositivo que no tiene 
más subdivisiones. En un disquete el primer sector siempre es un sector de arranque. MINIX permite una 
forma de subdivisión de un disquete, pero sólo la primera partición puede ser iniciada; no existe un 
registro de arranque maestro aparte, y no puede haber subparticiones. Esto permite montar los disquetes 
con y sin particiones exactamente de la misma manera. El uso principal de un disquete con particiones es 
dividir un disco de instalación en una imagen raíz que se copiará en un disco en RAM y una porción 
montada que podrá desmontarse cuando ya no se necesite, liberando así la unidad de disquete para 
continuar con el proceso de instalación. 

El sector de arranque de MINIX se modifica en el momento en que se escribe en el disco 
introduciendo los números de sector necesarios para encontrar un programa llamado boot en su partición o 
subpartición. Esta introducción es necesaria porque antes de que se cargue el sistema operativo no es 
posible usar el directorio y nombres de archivo para encontrar un archivo. Se utiliza un programa especial 
llamado installboot para realizar la introducción y la escritura del sector de arranque. Boot es el cargador 
secundario para MINIX, pero puede hacer más que simplemente cargar el sistema operativo, ya que es un 
programa monitor que permite al usuario modificar, establecer y guardar diversos parámetros. Boot 
examina el segundo sector de su partición en busca de un conjunto de parámetros que usará. MINIX, al 
igual que el UNIX estándar, reserva el primer bloque de 1K de todos los dispositivos de disco como 
bloque de arranque, pero el cargador de arranque en ROM o el sector maestro de arranque sólo carga un 
sector de 512 bytes, así que hay 512 bytes disponibles para guardar ajustes. Éstos controlan la operación 
de arranque, y también se pasan al sistema operativo mismo. Los ajustes por omisión presentan un menú 
con una sola opción, iniciar MINIX, pero es posible modificarlos de modo que presenten un menú más 
complejo que permita la iniciación de otros sistemas operativos (cargando y ejecutando sectores de 
arranque de otras particiones), o iniciar MINIX con diversas opciones. También podemos modificar los 
ajustes por omisión de modo que pasen por alto el menú e inicien MINIX de inmediato. 

Boot no forma parte del sistema operativo, pero tiene la suficiente inteligencia como para utilizar 
las estructuras de datos del sistema de archivos para encontrar la imagen del sistema operativo 
real. Por omisión, boot busca un archivo llamado ¡mmix o, si existe un directorio /minix/, 
el archivo más reciente dentro de ese directorio, pero es posible modificar los 
parámetros de arranque de modo que busquen un archivo con cualquier nombre. Este grado de flexibilidad 
es poco usual; la mayor parte de los sistemas operativos tienen un nombre de archivo predefinido 
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para la imagen del sistema. Por otro lado, MINIX es un sistema operativo poco usual que estimula a los 
usuarios para que lo modifiquen y creen versiones experimentales nuevas. La prudencia exige que los 
usuarios que hagan esto cuenten con un mecanismo para seleccionar múltiples versiones, y así poder 
regresar a la última versión que funcionó correctamente si es que llega a fallar un experimento. 

La imagen de MINIX cargada por boot no es más que una concatenación de los archivos 
individuales producidos por el compilador cuando compila los programas del kemel, el administrador de 
memoria, el sistema de archivos e mit. Cada uno de éstos incluye una cabecera corta del tipo de las que se 
definen en include/a.out.h, y, a partir de la información contenida en la cabecera de cada parte, boot 
determina cuánto espacio debe reservar para datos no inicializados después de cargar el código ejecutable 
y los datos inicializados de cada parte, con objeto de que la siguiente parte pueda cargarse en la dirección 
correcta. El arreglo sizes que mencionamos en la sección anterior también recibe una copia de esta 
información para que el kemel mismo pueda tener acceso a la ubicación y el tamaño de todos los módulos 
cargados por boot. Las regiones de la memoria disponibles para cargar el sector de arranque, boot mismo 
y MINIX dependen del hardware. Además, algunas arquitecturas de máquina pueden requerir un ajuste de 
las direcciones intemas dentro del código ejecutable a fin de convertirlas en las direcciones reales donde 
se cargan los programas. La arquitectura segmentada de los procesadores Intel hace que esto sea 
innecesario. Puesto que los detalles del proceso de carga difieren según el tipo de máquina, y boot en sí no 
forma parte del sistema operativo, no lo describiremos con mayor detalle aquí. Lo importante es que, de 
una forma u otra, el sistema operativo se carga en la memoria. Una vez cargado, el control pasa al código 
ejecutable del kemel. 

Como acotación, cabe señalar que los sistemas operativos no siempre se cargan de discos locales. 
Las estaciones de trabajo sin disco pueden cargar su sistema operativo de un disco remoto, a través de una 
conexión de red. Desde luego, esto requiere software de red en ROM. Aunque los detalles no son 
idénticos a los que hemos descrito aquí, lo más probable es que los elementos d proceso sean similares. El 
código en ROM debe tener la suficiente inteligencia como para ob a través de la red un archivo ejecutable 
que se encargará de obtener el sistema operativo completo. Si MINIX se cargara de esta forma, no sería 
necesario hacer muchos cambios al proceso de inicialización que ocurre una vez que el código del sistema 
operativo está cargado en la memoria. Desde luego, se requeriría un servidor de red y un sistema de 
archivos modificado capaz de acceder a los archivos a través de la red. 


2.6.6 Inicialización del sistema 


MINIX para máquinas tipo IBM PC se puede compilar en modo de 16 bits si se requiere compatibilidad 
con los procesadores Intel más antiguos, o en modo de 32 bits si se desea un mejor rendimiento 
en los procesadores 803 86+. Se usa el mismo código fúente en C y el compilador 
genera la salida apropiada dependiendo de si es la versión para 16 bits o 32 bits del compilador. 
Una macro definida por el compilador mismo determina la definición de la macro WORD SIZE 
que está en includelminixlconfig.h. La primera parte de MINIX que se ejecuta está escrita en 
lenguaje ensamblador, y se deben usar diferentes archivos de código fuente para el compilador de 16 bits 
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y el de 32 bits. La versión del código de inicialización para 32 bits está en mpx386.s. La alternativa, para 
los sistemas de 16 bits, está en mpx88.s. Ambos incluyen apoyo en lenguaje ensamblador para otras 
operaciones del kemel de bajo nivel. La selección se efectúa automáticamente en mpx.s. 

Este archivo es tan corto que podemos presentarlo completo en la Fig. 2-32. 

«tnctude <minix/config.h> 

#tf_WORD_SIZE = 2 
linclude "mpx88.s■ 

#«ls« 

#mdude "mpx386.s’ 

#end«f 

Figura 2-32. Forma como se seleccionan los archivos fuente en lenguaje ensamblador alternativos. 

Mpx.s muestra un uso poco común de la instrucción #include del preprocesador de C. Por lo 
regular, #include sirve para incluir archivos de cabecera, pero también puede utilizarse para seleccionar 
una sección alterna de código fuente. Si quisiéramos hacer esto usando instrucciones #if, tendríamos que 
colocar todo el código de los archivos mpx88.s y mpx386.s, que es muy extenso, en un solo archivo. Esto 
no sólo sería difícil de manejar; también desperdiciaría espacio de disco, pues en una instalación dada lo 
más probable es que uno de los dos archivos no se utilice en absoluto, y puede archivarse o eli mi narse. En 
la siguiente explicación usaremos el mpx386.s de 32 bits como ejemplo. 

Puesto que ésta es la primera vez que examinamos código ejecutable, comenzaremos con unas 
pocas palabras acerca de cómo haremos esto a lo largo del libro. Los múltiples archivos fúente que se usan 
para compilar un programa grande en C pueden ser difíciles de seguir. En general, limitaremos las 
explicaciones a un solo archivo a la vez, y veremos los archivos en orden. Comenzaremos con el punto de 
entrada de cada parte del sistema MINIX, y seguiremos la línea de ejecución principal. Cuando nos 
topemos con una llamada a una fúnción de apoyo, diremos unas cuantas palabras acerca del propósito de 
la llamada, pero normalmente no describiremos con detalle el funcionamiento intemo en ese punto; 
dejaremos eso para cuando lleguemos a la definición de la fúnción invocada. Las funciones subordinadas 
importantes por lo regular se definen en el mismo archivo en el que se invocan, después de las funciones 
invocadoras de nivel superior; pero las fruiciones pequeñas o de propósito general a veces se reúnen en 
archivos aparte. Además, se ha intentado colocar el código dependiente de la máquina y el independiente 
de la máquina en archivos distintos, a fin de facilitar el traslado a otras plataformas. Se ha hecho un 
esfuerzo considerable por organizar el código; de hecho, muchos archivos se reescribieron durante la 
redacción de este texto a fin de hacer su organización más comprensible para el lector. Sin embargo, un 
programa grande tiene muchas ramificaciones, y hay ocasiones en que para entender una función principal 
es necesario leer las funciones que invoca. Por ello, a veces es útil tener unas cuantas tiras de papel que 
puedan servir de marcadores en diversas partes del libro y desviarse del orden de las explicaciones para 
ver las cosas en un orden distinto. 

Habiendo planteado la forma en que pensamos organizar nuestra explicación 
del código, debemos comenzar por justificar de inmediato una excepción importante. El inicio de MINIX 
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implica varias transferencias de control entre las rutinas en lenguaje ensamblador de mpx386.s y rutinas 
escritas en C contenidas en los archivos start.c y main.c. Describiremos estas rutinas en el orden en que se 
ejecutan, aunque para ello sea necesario saltar de un archivo a otro. 

Una vez que el proceso de autoarranque ha cargado el sistema operativo en la memoria, se 
transfiere el control a la etiqueta MINIX (en mpx386.s, línea 6051). La primera instrucción hace que se 
pasen por alto unos cuantos bytes de datos; éstos incluyen las banderas del monitor de arranque (línea 
6054) que el monitor usa para identificar diversas características del kemel, siendo la más importante de 
ellas si se trata de un sistema de 16 o de 32 bits. El monitor de arranque siempre inicia en modo de 16 bits, 
pero conmuta la CPU a modo de 32 bits si es necesario. Esto sucede antes de que el control pase a MINIX. 
El monitor también prepara una pila. El código en lenguaje ensamblador tiene una buena cantidad de 
trabajo que realizar aquí: preparar un soporte de pila que ofrezca un entorno apropiado para el código 
compilado por el compilador de C, copiar tablas empleadas por el procesador para definir los segmentos 
de memoria, y configurar varios registros del procesador. Una vez terminado este trabajo, el proceso de 
inicialización continúa con la invocación (en la línea 6109) de la función cstart, que está en C. Observe 
que el código en lenguaje ensamblador se refiere a ella como cstart. La razón es que a los nombres de 
todas las funciones compiladas por el compilador de C se les antepone un carácter de subraya en las tablas 
de símbolos, y el enlazador busca esos nombres cuando enlaza módulos que se compilaron por separado. 
Puesto que el ensamblador no agrega tales caracteres, el escritor de un programa en lenguaje ensamblador 
debe agregar uno explícitamente para que el enlazador pueda encontrar un non-ibre correspondiente en el 
archivo objeto compilado por el compilador de C. Cstart invoca otra rutina para inicializar la tabla de 
descriptores globales, la estructura de datos central empleada por los procesadores Intel de 32 bits para 
supervisar la protección de memoria, y la tabla de descriptores de interrupciones, que sirve para 
seleccionar el código que se ejecutará al ocurrir cada tipo de interrupción. Al regresar de cstart, las 
instrucciones Igdt y Iidt (líneas 6115 y 6116) hacen efectivas estas tablas cargando los registros dedicados 
mediante los cuales se direccionan. La instrucción 

jmpf CS_SELECTOR:csinit 

parece a primera vista una operación nula, ya que transfiere el control al mismo lugar al que se transferiría 
si en lugar de ella hubiera una serie de instrucciones nop. No obstante, ésta es una parte importante del 
proceso de inicialización. Este salto obliga a usar las estructuras recién inicializadas. Después de 
manipular otro poco los registros del procesador, MINIX ter mi n a con un salto (no una llamada) en la línea 
6131 al punto de entrada main del kemel (en main. c). En este punto ha terminado el código de 
inicialización de mpx386.s. El resto del archivo contiene código para iniciar o reiniciar una tarea o 
proceso, manejadores de interrupciones y otras rutinas de apoyo que tuvieron que escribirse en lenguaje de 
ensamblador para que fueran eficientes. Volveremos a ellas en la siguiente sección. 

Examinemos ahora las funciones de inicialización en C de nivel más alto. La estrategia 
general es hacer lo más que se pueda usando código en C de alto nivel. Ya hay dos versiones del 
código mpx, como hemos visto, y todo lo que pueda descargarse a código en C elimina dos trozos de 
código ensamblador. Casi lo primero que hace cstart (en start.c, línea 6524) es configurar los mecanismos 
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de protección de la CPU y las tablas de interrupciones, mediante una invocación a pratmit. Luego, cstart 
copia los parámetros de arranque en la parte de la memoria que corresponde al kemel y los convierte en 
valores numéricos; además, determina el tipo de pantalla de video, el tamaño de la memoria, el tipo de 
máquina, el modo de operación del procesador (real o protegido) y si es posible o no regresar al monitor 
de arranque. Toda la información se almacena en variables globales apropiadas, a fin de que cualquier 
parte del código del kemel pueda acceder a ella si es necesario. 

Main (en main.c, línea 6721) completa la inicialización y luego inicia la ejecución normal del 
sistema. Esta función configura el hardware de control de interrupciones invocando a intrinit. Esto se 
hace aquí porque no puede hacerse antes de conocer el tipo de la máquina, y el procedimiento está en un 
archivo aparte porque depende mucho del hardware. El parámetro (1) en la llamada le dice a intr init que 
está inicializando para MINIX. Se puede llamar con un parámetro (O) para minicializar el hardware a su 
estado original. La llamada a intr init realiza también dos pasos para asegurar que cualquier interrupción 
que ocurra antes de haberse completado la inicialización no tendrá ningún efecto. Primero se escribe en 
cada uno de los chips controladores de interrupciones un byte que inhibe la respuesta a las entradas 
extemas. Luego, todas las entradas de la tabla empleada para acceder a los manejadores de interrupciones 
específicos para cada dispositivo se llenan con la dirección de una rutina que, sin perjudicar la 
inicialización, exhibirá un mensaje si se recibe una interrupción espuria. Más adelante estas entradas se 
reemplazarán, una por una, por apuntadores a las rutinas manejadoras, conforme cada una de las tareas de 
E/S ejecute su propia rutina de inicialización. Entonces, cada tarea restablecerá un bit en el chip 
controlador de interrupciones a fin de habilitar su propia entrada de interrupciones. 

A continuación se invoca me,n_init, que inicializa un arreglo que define la ubicación y el tamaño 
de cada región de memoria disponible en el sistema. Al igual que en la inicialización del hardware de 
interrupciones, los detalles dependen del hardware, y el aislamiento de meminit como función en un 
archivo aparte mantiene a main libre de código que no pueda trasladarse a un hardware distinto. 

La parte más grande del código de main se dedica a la preparación de la tabla de procesos, de modo 
que cuando se planifiquen las primeras tareas y procesos, sus mapas de memoria y registros se establezcan 
correctamente. Todas las ranuras de la tabla de procesos se marcan como desocupadas, y el ciclo de las 
líneas 6745 a 6749 inicializa el arreglo pprocaddr que agiliza el acceso a la tabla de procesos. El código 
de la línea 6748, 

(pprocaddr + NRTASKS) = rp; 

podría haberse definido también como pproc addr + NR TASKS] = rp; 

porque en el lenguaje C a es otra forma de escribir *(a+i). Por tanto, casi da lo mismo si sumamos una 
constante a a o a i. Algunos compiladores de C generan código que es un poco mejor si se suma una 
constante al arreglo en lugar de al índice. 

La parte más grande de main, el ciclo largo de las líneas 6762 a 6815, inicializa la tabla 
de procesos con la in formación necesaria para ejecutar las tareas, los servidores e mit. Todos 
estos procesos deben estar presentes en el momento del inicio y ninguno de ellos terminará durante el 
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funcionamiento normal. Al principio del ciclo, se asigna a rp la dirección de una entrada de la tabla de 
procesos (línea 6763). Puesto que rp es un apuntador a una estructura, se puede acceder a los elementos de 
dicha estructura usando una flotación como rp—>p_name, como se hace en la línea 6765. Esta notación se 
usa mucho en el código fuente de MINIX. 

Por supuesto, todas las tareas se compilan en el mismo archivo que el kemel, y la información 
referente a sus necesidades de pila está en el arreglo tasktab definido en table.c. Puesto que las tareas se 
compilan junto con el kemel y pueden invocar código y acceder a datos situados en cualquier parte del 
espacio del kemel, el tamaño de una tarea individual no es significativo, y el campo de tamaño para cada 
una de ellas se llena con el tamaño del kemel mismo. El arreglo sizes contiene los tamaños en clicks del 
texto y los datos del kemel, el administrador de memoria, el sistema de archivos e mit. Esta información 
fue introducida en el área de datos del kemel por boot antes de que el kemel iniciara su ejecución, y desde 
el punto de vista del kemel es como si el compilador la hubiera proporcionado. Los dos primeros 
elementos de sizes son los tamaños del texto y los datos del kemel; los siguientes dos son los del 
administrador de memoria, etc. Si alguno de los cuatro programas no usa espacio 1 y D separado, el 
tamaño del texto es O y el texto y los datos se agrupan como datos. Al asignarse a sizeindex un valor de 
cero (línea 6775) para cada una de las tareas se asegura que se accederá al elemento número O de sizes 
para todas las tareas en las líneas 6783 y 6784. La asignación a sizeindex de la línea 6778 sumi ni stra a 
cada uno de los servidores y a mit su propio índice para acceder a sizes. 

El diseño de la IBM PC original colocaba la memoria sólo de lectura en la parte superior del 
intervalo de memoria utilizable, que está limitado a 1 MB en una CPU 8088. Las máquinas modernas 
compatibles con PC siempre tienen más memoria que la PC original, pero por compatibilidad todavía 
tienen la memoria sólo de lectura en las mismas direcciones que las máquinas antiguas. Así, la memoria 
de leer-escribir es discontinua, con un bloque de ROM entre los 640 KB inferiores y el intervalo por 
encima de 1 MB. Si es posible, el monitor de arranque carga los servidores e mit en el intervalo de 
memoria situado por arriba de laROM. Esto se hace principalmente pensando en el sistema de archivos, a 
fin de que-pueda usar un caché de bloques muy grande sin toparse con la memoria sólo de lectura. El 
código condicional de las líneas 6804 a 6810 asegura que este uso del área de memoria alta quede 
registrado en la tabla de procesos. 

Dos entradas de la tabla de procesos corresponden a procesos que no necesitan planificarse de 
forma ordinaria. Estos procesos son IDLE y HARDWARE. IDLE es un ciclo que no hace nada y que se 
ejecuta cuando ningún otro proceso está listo para ejecutarse. HARDWARE existe para propósitos de 
contabilización; a él se acredita el tiempo usado mientras se atiende una interrupción. El código de la línea 
6811 coloca todos los demás procesos en las colas apropiadas. La fúnción que se invoca, lock ready, 
establece una variable de candado, switching, antes de modificar las colas, y luego quita el candado una 
vez que la cola se ha modificado. El empleo de candados no es necesario en este momento en el que nada 
se está ejecutando todavía, pero éste es el método estándar, y no tiene caso crear código extra que se usará 
sólo una vez. 

El último paso para inicializar cada ranura de la tabla de procesos es una invocación 
a allocsegments. Este procedimiento forma parte de la tarea del sistema, pero como todavía 
no se está ejecutando ninguna tarea se invoca como procedimiento ordinario en la línea 6814. Se trata 
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de una rutina dependiente de la máquina que coloca en los campos apropiados las ubicaciones, tamaños y 
niveles de permiso para los segmentos de memoria utilizados por cada proceso. En el caso de los 
procesadores Intel más antiguos que no manejan el modo protegido, esta rutina sólo define la ubicación de 
los segmentos, y tendría que reescribirse para manejar un tipo de procesador con un método de reparto de 
memoria distinto. 

Una vez inicializada la tabla de procesos para todas las tareas, los servidores e mit, el sistema ya 
casi está listo para ponerse a trabajar. La variable bill_ptr indica a cuál proceso se le cobrará el tiempo de 
procesador; es necesario asignarle un valor inicial en la línea 6818, e IDLE es una buena opción. Más 
adelante podría ser modificada por la siguiente función invocada, lock_pick_proc. Todas las tareas están 
listas ya para ejecutarse, y bill_ptr se modificará cuando se ejecute un proceso de usuario. La otra 
obligación de lock_pick_proc es hacer que la variable pmc_ptr apunte a la entrada de la tabla de procesos 
correspondiente al siguiente proceso por ejecutar. Esta selección se efectúa examinando las colas de 
tareas, servidores y procesos de usuario, en ese orden. En este caso, el resultado es que proc_ptr apunta al 
punto de entrada de la tarea de la consola, que siempre es la primera en iniciarse. 

Por fin ha terminado main. En muchos programas en C main es un ciclo, pero en el kemel de 
MINIX su trabajo está hecho una vez que se completa la inicialización. La llamada a restart de la línea 
6822 inicia la primera tarea. El control nunca volverá a main. 

Restart es una rutina en lenguaje ensamblador que está en mpx386.s. De hecho, restart no es una 
función completa; es un punto de entrada intermedio de un procedimiento mayor. Examinaremos esta 
rutina con detalle en la siguiente sección; por ahora sólo diremos que restart causa la conmutación de 
contexto, así que se ejecutará el proceso al que apuntaproc_ptr. Una vez que restart se ha ejecutado por 
vez primera ya podemos decir que MINIX está funcionando: está ejecutando un proceso. Restart se 
ejecuta una y otra vez conforme se da oportunidad a las tareas, servidores y procesos de usuario de 
ejecutarse, para luego ser suspendidos, ya sea en espera de entradas o para ceder el tumo a otros procesos. 

La tarea que se pone en cola primero (la que usa la ranura O de la tabla de procesos, es decir, la 
que tiene el número más negativo) siempre es la tarea de la consola, a fin de que otras tareas puedan usarla 
para in formar de su avance o de los problemas que enfrenten una vez que se inicien. La tarea de la consola 
se ejecuta hasta que se bloquea tratando de recibir un mensaje. A continuación se ejecutará la siguiente 
tarea hasta que ella también se bloquee tratando de recibir un mensaje. Tarde o temprano todas las tareas 
estarán bloqueadas, y el administrador de memoria y el sistema de archivos podrán ejecutarse. Al 
ejecutarse por primera vez, cada uno de ellos realiza algunas operaciones de inicialización, pero llegará el 
momento en que ambos queden bloqueados también. Por último, mit bifurcará un proceso getly para cada 
terminal. Estos procesos se bloquearán hasta que se teclee alguna entrada en alguna terminal, y en ese 
momento el primer usuario podrá iniciar una sesión. 

Ya hemos seguido el inicio de MINIX a través de tres archivos, dos escritos en C y uno en 
lenguaje ensamblador. El archivo en lenguaje ensamblador, mpx386.s, contiene código adicional 
que se usa para manejar interrupciones, cosa que veremos en la siguiente sección. Sin embargo, 
antes de continuar describiremos brevemente las rutinas restantes de los dos archivos 
en C. Los otros procedimientos de start.c son k atoi (línea 6594) que convierte una cadena en un entero, y 
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kgetenv (línea 6606), que sirve para encontrar entradas en el entorno del kemel, que es una copia de los 
parámetros de arranque. Ambos son versiones simplificadas de funciones de biblioteca estándar que se 
reescriben aquí con objeto de reducir la complejidad del kemel. El único procedimiento que quedaba sin 
mención en main.c es panic (línea 6829), que se invoca cuando el sistema descubre una condición que le 
impide continuar. Las condiciones de pánico típicas son la imposibilidad de leer un bloque de disco 
crítico, la detección de un estado intemo inconsistente, o que una parte del sistema invoque a otra con 
parámetros no válidos. Las llamadas a print» aquí son en realidad llamadas a la rutina del kemel printk, a 
fin de que el kemel pueda escribir en la consola aun cuando la comunicación entre procesos normal haya 
quedado interrumpida. 


2.6.7 Manejo de interrupciones en MÍNIX 


Los detalles del hardware de interrupciones dependen del sistema, pero todo sistema debe contar con 
elementos funcionales equivalentes a los que describiremos para sistemas con una CPU Intel de 32 bits. 
Las interrupciones generadas por dispositivos de hardware son señales eléctricas y al principio son 
manejadas por un controlador de interrupciones: un circuito integrado que puede detectar varias de esas 
señales y generar para cada una, una disposición de datos única en el bus de datos del procesador. Esto es 
necesario porque el procesador en sí sólo tiene una entrada para detectar todos estos dispositivos y, por 
tanto, es incapaz de distinguir cuál de ellos está solicitando servicio. Las PC que usan procesadores Intel 
de 32 bits normalmente vienen equipadas con dos de estos chips controladores. Cada uno de ellos puede 
manejar ocho entradas, pero uno es un esclavo que alimenta su salida a una de las entradas del maestro, de 
modo que la combinación puede detectar quince dispositivos extemos distintos, como se aprecia en la Lig. 
2-33. 
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Figura 2-33. Hardware de procesamiento de interrupciones en una PC Intel de 32 bits. 
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En la figura, las señales de interrupción llegan por las distintas líneas JRQ n indicadas a la 
derecha. La conexión con el pm INT de la CPU le dice al procesador que ha ocurrido una interrupción. La 
señal INTA (acuse de interrupción) de la CPU hace que el controlador responsable de la interrupción 
coloque datos en el bus de datos del sistema para indicarle al procesador cuál rutina de servicio debe 
ejecutar. Los chips controladores de interrupciones se programan durante la inicialización del sistema, 
cuando main invoca a intr init. La programación determina la salida que se envía a la CPU para cada 
señal recibida por cada una de las líneas de entrada, así como varios otros parámetros del funcionamiento 
del controlador. Los datos que se colocan en el bus son un número de 8 bits que se usa como índice de una 
tabla de hasta 256 elementos. La tabla de MINIX tiene 56 elementos, de los cuales sólo se usan realmente 
35; los demás están reservados para utilizarse con procesadores Intel futuros o para mejoras futuras de 
MINIX. En los procesadores Intel de 32 bits esta tabla contiene descriptores de puertas de interrupción, 
cada uno de los cuales es una estructura de 8 bytes con varios campos. 

Hay varios modos posibles de responder a las interrupciones; en el que se usa con MINIX, los 
campos que más nos interesan de los descriptores de puertas de interrupción apuntan al segmento de 
código ejecutable de la rutina de servicio y a la dirección inicial dentro de él. La CPU ejecuta el código al 
que apunta el descriptor seleccionado. El resultado es exactamente el mismo que si se ejecutara una 
instrucción de lenguaje ensamblador 

int < nnn > 

La única diferencia es que en el caso de una interrupción de hardware la parte < nnn > se origina en un 
registro del chip controlador de interrupciones, y no en una instrucción que está en la memoria del 
programa. 

El mecanismo de conmutación de tareas que entra en acción como respuesta a una interrupción en 
un procesador Intel de 32 bits es complejo, y la modificación del contador de programa para ejecutar otra 
Junción es sólo una parte. Cuando la CPU recibe una interrupción durante la ejecución de un proceso, 
establece una nueva pila para usarla mientras atiende la interrupción. La ubicación de esta pila está 
determinada por una entrada del segmento de estado de tareas (TSS). Ésta es una estructura única para 
todo el sistema, que se inicializa cuando cstart invoca prot init y se modifica cada vez que se inicia un 
proceso. El efecto es que la nueva pila creada por una interrupción siempre comienza al final de la 
estructura stackframes dentro de la entrada correspondiente al proceso interrumpido en la tabla de 
procesos. La CPU agrega automáticamente varios registros clave en esta nueva pila, incluidos los 
necesarios para reinstaurar la pila del proceso interrumpido y restablecer su contador de programa. Una 
vez que el código del manejador de interrupciones empieza a ejecutarse, usa esta área de la tabla de 
procesos como su pila, pero gran parte de la información necesaria para regresar al proceso interrumpido 
ya se habrá almacenado. El manejador de interrupciones agrega en la pila el contenido de registros 
adicionales, llenando el marco de pila, y luego pasa a una pila provista por el kemel mi entras hace lo 
necesario para atender la interrupción. 

La ter mi nación de una rutina de servicio de interrupción se efectúa pasando de la pila del 
kemel a un marco de pila en la tabla de procesos (pero no necesariamente el mismo 
que creó la última interrupción), removiendo explícitamente los registros adicionales, y ejecutando una 
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instrucción iretd (retomo de interrupción). Iretd restaura el estado que existía antes de una interrupción, 
restaurando los registros agregados por el hardware y conmutando de vuelta a una pila que se estaba 
usando antes de una interrupción. Así, una interrupción detiene un proceso, y la finalización del servicio 
de la interrupción reinicia un proceso, que podría ser distinto del que se detuvo más recientemente. A 
diferencia de los mecanismos de interrupción más sencillos que son el tema usual de los textos sobre 
programación en lenguaje de ensamblador, nada se almacena en la pila de trabajo del proceso 
interrumpido durante una interrupción. Además, dado que la pila se crea de nuevo en una posición 
conocida (determinada por el TSS) después de una interrupción, se simplifica el control de múltiples 
procesos. Si se desea iniciar un proceso distinto lo único que se necesita es hacer que el apuntador de pila 
apunte al marco de pila de otro proceso, restaurar los registros que se agregaron explícitamente, y ejecutar 
una instrucción iretd. 

La CPU inhabilita todas las interrupciones cuando recibe una interrupción. Esto garantiza que nada 
podrá ocurrir que haga que el marco de pila dentro de una entrada de la tabla de procesos se desborde. 
Esto es automático, pero también existen instrucciones en el nivel de ensamblador para inhabilitar y 
habilitar las interrupciones. El manejador de interrupciones vuelve a habilitar las interrupciones después 
de pasar a la pila del kemel, situada fuera de la tabla de procesos. Desde luego, el manejador debe 
inhabilitar otra vez todas las interrupciones antes de pasar de nuevo a una pila dentro de la tabla de 
procesos, pero mientras está manejando una interrupción pueden ocurrir otras interrupciones y ser 
procesadas. La CPU sigue la pista a las interrupciones anidadas, y se vale de un método más sencillo de 
pasar a una rutina de servicio de interrupción y regresar de una cuando se interrumpe un manejador de 
interrupciones. Si se recibe una interrupción nueva mientras se está ejecutando un manejador (u otro 
código del kemel), no se crea una nueva pila. En vez de ello, la CPU agrega a la pila existente los registros 
esenciales necesarios para reanudar el código interrumpido. Cuando se encuentra un iretd durante la 
ejecución de código del kemel, se usa también un mecanismo de retomo más simple. El procesador puede 
determinar cómo debe manejar el iretd examinando el selector de segmento de código que se remueve de 
la pila como parte de la acción del iretd. 

Los niveles de privilegio que mencionamos antes controlan las diferentes respuestas a las 
interrupciones que se reciben mientras se está ejecutando un proceso y mientras se está ejecutando código 
del kemel (incluidas las rutinas de servicio de interrupción). Se usa el mecanismo más sencillo cuando el 
nivel de privilegio del código interrumpido es el mismo que el del código que se ejecutará como respuesta 
a la interrupción. Sólo cuando el código interrumpido es menos privilegiado que el código de servicio de 
interrupción se usa el mecanismo más complicado, utilizando el TSS y una nueva pila. El nivel de 
privilegio de un segmento de código se registra en el selector de segmentos de código, y como ésta es una 
de las cosas que se agregan durante una interrupción, se puede examinar después de regresar de la 
interrupción para determinar lo que debe hacer la instrucción retd. El hardware proporciona otro servicio 
cuando se crea una nueva pila para usarla mientras se atiende una interrupción. El hardware verifica que la 
nueva pila tenga el tamaño suficiente para guardar cuando menos la cantidad mínima de información 
que debe colocarse en ella. Esto protege al código de kemel más privilegiado contra una falla accidental 
(o premeditada) causada por un proceso de usuario que realiza una llamada al sistema con una pila 
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insuficiente. Estos mecanismos se incorporan en el procesador específicamente para utilizarse en la 
implementación de sistemas operativos que manejan múltiples procesos. 

Este comportamiento puede causar confusión si no se conoce el funcionamiento intemo de las 
CPU Intel de 32 bits. Normalmente tratamos de evitar la descripción de tales detalles, pero es 
indispensable entender qué sucede cuando ocurre una interrupción y cuando se ejecuta una instrucción 
iretd para poder entender cómo el kemel controla las transiciones de y hacia el estado “ejecutándose” de la 
Fig. 2-2. El hecho de que el hardware se encargue de gran parte del trabajo facilita mucho las cosas para el 
programador, y es de suponer que hace al sistema resultante más eficiente. Toda esta ayuda del hardware, 
empero, dificulta el entendimiento de lo que está sucediendo si sólo leemos el software. 

Sólo una pequeñísima parte del kemel de MINIX ve realmente las interrupciones de hardware. 
Este código está en mpx386.s. Hay un punto de entrada para cada interrupción. El código fuente en cada 
punto de entrada, hwintOO a _hwint07 (líneas 6164 a 6193), parece una llamada a hwintmaster (línea 
6143), y los puntos de entrada _hwint08 a _hwintl5 (líneas 6222 a 6251) parecen llamadas a hwintslave 
(línea 6199). Cada punto de entrada aparentemente pasa un parámetro en la llamada, indicando cuál 
dispositivo requiere servicio. En realidad, éstas no son realmente llamadas, sino macros, y se ensamblan 
ocho copias individuales del código definido por la definición de macro de hwint master que sólo difieren 
en el parámetro irq. De forma similar, se ensamblan ocho copias de la macro hwint slave. Esto puede 
parecer extravagante, pero el código ensamblado es muy compacto. El código objeto para cada macro 
expandida ocupa menos de 40 bytes. Al atender una interrupción, la rapidez es crucial, y cuando se 
efectúa de este modo se elim in a el gasto extra de ejecutar código para cargar un parámetro, invocar una 
subrutina y recuperar el parámetro. 

Continuaremos la explicación de hwint master como si en realidad fuera una sola función, y no 
una macro que se expande en ocho lugares distintos. Recuerde que antes de que hwint master inicie su 
ejecución, la CPU ha creado una nueva pila en el stackframes del proceso interrumpido, dentro de su 
ranura de la tabla de procesos, y que ya se guardaron ahí varios registros clave. La primera acción de 
hwint master es invocar save (línea 6144). Esta subrutina agrega todos los demás registros necesarios para 
reiniciar el proceso interrumpido. Se podría haber escrito save en línea como parte de la macro a fin de 
aumentar la rapidez, pero esto habría aumentado a más del doble el tamaño de la macro, y además hay 
otras fúnciones que invocan save. Como veremos, save hace malabarismos con la pila. Al regresar a 
hwint master, se está usando la pila del kemel, no un marco de pila de la tabla de procesos. El siguiente 
paso consiste en manipular el controlador de interrupciones, a fin de evitar que reciba otra interrupción del 
dispositivo que generó la interrupción actual (líneas 6145 a 6147). Esta operación enmascara la capacidad 
del chip controlador de responder a una entrada especifica; la capacidad de la CPU para responder a todas 
las interrupciones se inhibe internamente desde el momento en que recibe la señal de interrupción, y a 
estas alturas todavía no ha sido restablecida. 

El código de las líneas 6148 a 6150 restablece el controlador de interrupciones y luego 
habilita la CPU para recibir otra vez interrupciones de otros dispositivos. A continuación, la 
instrucción cali indirecta de la línea 6152 usa el número de la interrupción que está siendo atendida como 
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índice para acceder a una tabla de direcciones de las rutinas de bajo nivel específicas para cada 
dispositivo. Decimos que estas rutinas son de bajo nivel, pero están escritas en C, y por lo regular realizan 
operaciones tales como dar servicio a un dispositivo de entrada y transferir los datos a un buffer donde 
estará accesible para la tarea correspondiente cuando ésta tenga su siguiente oportunidad de ejecutarse. 
Puede haber una cantidad considerable de procesamiento antes de regresar de esta llamada. 

Veremos ejemplos de código controlador de bajo nivel en el siguiente capítulo. No obstante, a 
fin de entender lo que está sucediendo aquí en hwintmaster, mencionaremos que el código de bajo nivel 
puede invocar interrupt (enproc.c, que veremos en la siguiente sección), y que interrupt transforma la 
interrupción en un mensaje dirigido a la tarea que da servicio al dispositivo que causó la interrupción. 
Además, una llamada a interrupt invoca al planificador, el cual puede seleccionar esta tarea para ser 
ejecutada a continuación. Al regresar de la llamada al código específico para el dispositivo, se vuelve a 
inhabilitar la capacidad del procesador para responder a todas las interrupciones, mediante la instrucción 
cli de la línea 6154, y el controlador de interrupciones queda preparado para poder responder al 
dispositivo específico que causó la interrupción en curso cuando se vuelvan a habilitar todas las 
interrupciones (líneas 6157 a 6159). Luego, hwint master termina con una instrucción ret (línea 6160). No 
es obvio que aquí esté ocurriendo algo engañoso. Si lo que se interrumpió fue un proceso, la pila que se 
está usando en este punto es la del kemel, no la pila dentro de la tabla de procesos que el hardware 
configuró antes de que se iniciara hwint master. En este caso, la manipulación de la pila por save habrá 
dejado la dirección de restart en la pila del kemel. Esto hará que se ejecute otra vez una tarea, servidor o 
proceso de usuario que podría no ser (y de hecho es poco probable que sea) el mismo proceso que se 
estaba ejecutando originalmente. Esto depende de si el procesamiento del mensaje creado por la rutina de 
servicio de interrupción específica para el dispositivo causó o no un cambio en las colas de planificación 
de procesos. Éste es, pues, el corazón del mecanismo que crea la ilusión de múltiples procesos que se 
ejecutan simultáneamente. 

Para no dejar cabos sueltos, mencionemos que cuando ocurre una interrupción mientras se está 
ejecutando código del kemel la pila del kemel ya está en uso, y save deja la dirección de restarti en la pila 
del kemel. En este caso, lo que sea que el kemel haya estado haciendo previamente continuará después del 
ret al final de hwint master. Por tanto, las interrupciones pueden anidarse, pero una vez que han terminado 
todas las rutinas de servicio de bajo nivel se ejecuta finalmente restart, y puede ser que se ponga en 
ejecución un proceso distinto del que fue interrumpido. 

Hwinrslave (línea 6199) es muy similar a hwint master, excepto que debe volver a habilitar 
ambos controladores maestro y esclavo, ya que ambos quedan inhabilitados cuando el esclavo recibe una 
interrupción. Aquí hay unos cuantos aspectos sutiles del lenguaje ensamblador que debemos examinar. 
Primero, en la línea 6206 vemos 

jmp .+2 

que especifica un salto cuya dirección objetivo es la instrucción que le sigue inmediatamente. Esta 
instrucción se coloca aquí únicamente para agregar un pequeño retardo. Los autores del 
IBM PC BIOS original consideraron que era necesario un retardo entre instrucciones de E/S 
consecutivas, y estamos siguiendo su ejemplo, aunque tal vez no sea necesario en todas las computadoras 
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compatibles con IBM PC modernas. Esta clase de afinación es una de las razones por las que aI81mos 
consideran la programación de dispositivos de hardware como un arte esotérico. En la línea 6214 hay un 
salto condicional a una instrucción con un rótulo numérico, 

O: ret 

que se encuentra en la línea 6128. Observe que la línea 
jz Of 

no especifica el número de bytes que deben saltarse, como en el ejemplo anterior. El Of aquí no es un 
número hexadecimal. Ésta es la forma en que el ensamblador utilizado por el compilador de MINIX 
especifica un rótulo local; Of significa saltar hacia adelante (“forward”) al siguiente rótulo numérico O. 
Los nombres de rótulos ordinarios no pueden comenzar con caracteres numéricos. Otro punto interesante 
y tal vez confuso es que el mismo rótulo ocurre en otro lugar del mismo archivo, en la línea 6160 de 
hwintmaster. La situación es aún más complicada de lo que parece a primera vista, ya que estos rótulos 
están dentro de macros y las macros se expanden antes de que el ensamblador vea este código. Por tanto, 
en realidad hay 16 rótulos 0: en el código que el código ensamblador ve. La posible proliferación de 
rótulos declarados dentro de macros es, de hecho, la razón por la que el lenguaje ensamblador proporciona 
rótulos locales; para resolver un rótulo local el ensamblador usa el más cercano que coincide en la 
dirección especificada, y hace caso omiso de las demás ocurrencias del rótulo local. 

Examinemos ahora save (línea 6261), al que ya hemos mencionado varias veces. Su nombre 
describe una de sus funciones, que es guardar el contexto del proceso interrumpido en la pila provista por 
la CPU. Esta pila es un marco de pila dentro de la tabla de procesos. Save usa la variable kreenter para 
contar y determinar el nivel de anidación de las interrupciones. Si se estaba ejecutando un proceso cuando 
ocurrió la interrupción actual, la instrucción 

mov esp, k stktop 

de la línea 6274 pasa a la pila del kemel, y la siguiente instrucción agrega la dirección de restart (línea 
(6275). Si no se estaba ejecutando ningún proceso, ya se está usando la pila del kemel, y lo que se agrega 
es la dirección de restarti (línea 6281). En ambos casos, una instrucción retum ordinaria no es suficiente 
para regresar al invocador, pues cabe la posibilidad de que se esté usando una pila distinta de la que estaba 
vigente al ingresar, y de que la dirección de retomo de la rutina invocadora esté enterrada bajo los 
registros que acaban de agregarse. Las instrucciones 

jmp RETADR-PSTACKBASE(eax) 

que dan término a los dos puntos de salida de save, en las líneas 6277 y 6282 respectivamente, utilizan la 
dirección que se agregó cuando se invocó save. 

El siguiente procedimiento de mpx386.s es scall, que comienza en la línea 6288. Antes de 
examinar sus detalles intemos, vea cómo termina. No hay ningún ret ni jmp al final. Después de 
inhabilitarse las interrupciones con cli en la línea 6315, la ejecución continúa con restart. S call es la 
contraparte de llamada al sistema del mecanismo de manejo de interrupciones. El 
control llega a s call después de una interrupción de software, es decir, una ejecución de una instrucción 
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int nnn . Las interrupciones de software se tratan como interrupciones de hardware, excepto desde luego 
que el índice para acceder a la tabla de descriptores de interrupciones está codificado en la parte nnn de la 
instrucción mt nnn, en lugar de ser proporcionado por un chip controlador de interrupciones. Así, cuando 
se ingresa en scall, la CPU ya se pasó a una pila dentro de la tabla de procesos (suministrada por el 
Segmento de Estado de Tareas) y ya se han agregado varios registros en esta pila. Al continuar con 
restart, la llamada a s call en última instancia termina con una instrucción iretd y, al igual que en el 
caso de una interrupción de hardware, esta instrucción iniciará el proceso al que apunte proc_ptr en ese 
momento. En la Fig. 2-34 se compara el manejo de una interrupción de hardware y una llamada al sistema 
empleando el mecanismo de interrupción de software. 



(a) (•) 


Figura 2-34. (a) Procesamiento de una interrupción de hardware, (b) Ejecución de una 
llamada al sistema 


Veamos ahora algunos de los detalles de s call. La etiqueta alterna, _p_s_call, es un vestigio de 
la versión de MINIX para 16 bits, que tiene rutinas individuales para operar en modo protegido y en modo 
real. En la versión para 32 bits todas las llamadas a cualquiera de esas etiquetas viene a dar aquí. Un 
programador que invoca una llamada al sistema de MINIX escribe una llamada de función en C que se ve 
como cualquier otra llamada de función, sea a una función definida local mente o a una rutina de la 
biblioteca de C. El código de biblioteca que apoya la llamada al sistema prepara un mensaje, carga la 
dirección del mensaje y el identificador de proceso del destino en registros de la CPU, y luego invoca una 
instrucción mt SYS386 VECTOR. Como se explicó antes, el resultado es que el control pasa al inicio de 
s call, y varios registros ya se han agregado en una pila dentro de la tabla de procesos. 














SEC. 2.6 


IMPLEMENTACIÓN DE PROCESOS EN MINIX 


135 


La primera parte del código de scall se parece a una expansión en línea de save y guarda 
registros adicionales que deben preservarse. Al igual que en save, una instrucción 

Mov esp, kstktop 

Pasa entonces a la pila del kemel, y se vuelven a habilitar las interrupciones. (La similitud entre 
interrupción de software y una de hardware se extiende a que ambas inhabilitan todas las interrupciones.) 
Después de esto viene una llamada a syscall, que veremos en la siguiente i4e. Por ahora sólo diremos 
que esta función hace que se entregue un mensaje, y que esto a su vez hace que se ejecute el planificador. 
Por tanto, cuando sys call regresa, es probable que proc...ptr esté apuntando a un proceso distinto del que 
inició la llamada al sistema. Antes de que la ejecución continúe con restart, una instrucción cli inhabilita 
las interrupciones a fin de proteger el marco de pila del proceso que está a punto de ser reiniciado. 

Hemos visto que puede llegarse a restart (línea 6322) de varias maneras: 

1. Por una llamada desde main cuando se inicia el sistema. 

2. Por un salto desde hwint_,naster o hwint slave después de una interrupción de hardware. 

3. Continuando al fin al de s call después de una llamada al sistema. 

En todos los casos las interrupciones se inhabilitan en este punto. Restart llama a unhoid si detecta que se 
ha detenido alguna interrupción no atendida porque llegó mi entras se estaban procesando otras 
interrupciones. Esto permite convertir las otras interrupciones en mensajes antes de que se reinicie 
cualquier proceso. Las interrupciones quedan habilitadas otra vez temporalmente, pero se inhabilitan de 
nuevo antes de que unhoid regrese. A la altura de la línea 6333 ya se ha escogido definitivamente el 
siguiente proceso que se ejecutará, y con las interrupciones inhabilitadas la decisión no puede cambiarse. 
La tabla de procesos se construyó cuidadosamente de modo que comenzara con un soporte de pila, y la 
instrucción de esta línea, 

mov esp, (_proc_ptr) 

hace que el registro apuntador a la pila de la CPU apunte al marco de pila. A continuación, la ins trucción 
lldt PLDTSEL(esp) 

carga el registro de la tabla de descriptores local del procesador con un valor tomado del marco de pila. 
Esto prepara al procesador para usar los segmentos de memoria que pertenecen al siguiente proceso por 
ejecutar. La siguiente instrucción pone la dirección contenida en la entrada correspondiente al siguiente 
proceso en la tabla de procesos para que indique dónde se establecerá la pila para la siguiente interrupción, 
y la siguiente instrucción almacena dicha dirección en el TSS. La primera parte de restart no es 
necesaria después de una interrupción que ocurre cuando se está ejecutando código 
del kemel (incluido código de servicio de interrupción), puesto que se estará usando la pila del 
kemel y la ter mi n a ción del servicio de interrupción deberá permitir que el código de kemel 
continúe. La etiqueta restarti (línea 6337) marca el punto donde se reanuda la 
ejecución en este caso. En este momento se decrementa k reenter a fin de registrar que se ha dado 
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cuenta de un nivel de interrupciones posiblemente anidadas, y el resto de las instrucciones restablecen el 
procesador al estado en el que estaba cuando el siguiente proceso se ejecutó por última vez. La penúltima 
instrucción modifica el apuntador a la pila de modo que se pase por alto la dirección de retomo que se 
agregó cuando se invocó save. Si la última interrupción ocurrió cuando se estaba ejecutando un proceso, la 
instrucción final, iretd, completa el retomo a la ejecución del proceso al que ahora se le va a permitir 
ejecutarse, restaurando sus registros restantes, incluido su segmento de pila y apuntador a la pila. Por otro 
lado, si este encuentro con iretd sucedió por la vía de restarti, la pila del kemel en uso no es un marco de 
pila sino la pila del kemel, y no se trata de un retomo a un proceso interrumpido, sino la finalización de 
una interrupción que ocurrió mientras se estaba ejecutando código del kemel. La CPU detecta esto cuando 
el descriptor del segmento de código se saca de la pila durante la ejecución del iretd, y la acción completa 
del iretd en este caso es mantener en uso la pila del kemel. 

Hay unas cuantas cosas más que comentar en mpx386.s. Además de las interrupciones de hardware 
y software, diversas condiciones de error internas de la CPU pueden causar la iniciación de una excepción. 
Las excepciones no siempre son malas; pueden servir para estimular al sistema operativo para que 
proporcione un servicio, como suministrar más memoria a un proceso, o intercambiar hacia adentro una 
página de memoria que se intercambió hacia afúera, aunque tales servicios no se implementan en el 
MINIX estándar. Sin embargo, cuando ocurre una excepción, no debe hacerse caso omiso de ella. El 
mismo mecanismo que maneja las interrupciones maneja las excepciones, empleando descriptores de la 
tabla de descriptores de interrupciones. Estas entradas de la tabla apuntan a los 16 puntos de entrada de 
manejador de excepciones, comenzando con divide error y terminando con copr error, que se 
encuentra cerca del final de mpx386.s, en las líneas 6350 a 6412. Todos éstos saltan a exception (línea 
6420) o a errexception (línea 6431), dependiendo de si la condición agrega a la pila un código de error o 
no. El manejo aquí en el código de ensamblador es similar al que ya vimos: se agregan registros y se 
invoca la rutina en C exception (tome nota del carácter de subraya) para manejar el evento. Las 
consecuencias de las excepciones varían. Algunas se ignoran, otras causan pánicos, y otras más causan el 
envío de señales a procesos. Examinaremos exception en una sección posterior. 

Existe un punto de entrada más que se maneja como una interrupción, levelO cali (línea 6458). 
Explicaremos su fúnción en la siguiente sección, cuando veamos el código al que salta, levelO func. El 
punto de entrada está aquí en mpx360.s junto con los puntos de entrada de interrupciones y excepciones 
porque también se invoca mediante la ejecución de una instrucción /nt. Al igual que las rutinas de 
excepción, esta rutina invoca save, así que tarde o temprano el código al que se salta aquí terminará con un 
ret que conduce a restart. La última función ejecutable de mpx386.s es idle task (línea 6465). Éste es un 
ciclo que no hace nada y que se ejecuta cuando no hay ningún otro proceso listo para ejecutarse. 

Por último, se reserva un poco de espacio para almacenar datos al final del archivo en lenguaje 
ensamblador. Aquí se definen dos segmentos de datos distintos. La declaración 

.sect .rom 

de la línea 6478 asegura que este espacio se asignará exactamente al principio del segmento de 
datos del kemel. El compilador coloca un número mágico aquí para que boot pueda verificar que 
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el archivo que carga es una imagen de kemel válida. A continuación boot sobreescribe el número mágico 
y el espacio subsecuente con los datos del arreglo sizes, como se explicó al hablar de las estructuras de 
datos del kemel. Se reserva suficiente espacio aquí para un arreglo sizes con un 16 entradas, en caso de 
que se agreguen servidores adicionales a MINIX. La otra área de nacimiento de datos definida en la 
declaración 

.sect .bss 

(línea 6483) reserva espacio en el área de variables no inicializadas normal del kemel para la pila del 
kemel y para variables utilizadas por los manejadores de excepciones. Se reserva espacio de pila para los 
servidores y procesos ordinarios cuando se enlaza un archivo ejecutable, y éstos dependen del kemel para 
que ajuste correctamente el descriptor de segmento de pila y el apuntador a la pila cuando se ejecutan. El 
kemel tiene que hacer esto por sí mismo. 


2.6.8 Comunicación entre procesos en MINIX 

En MINIX los procesos se comunican con mensajes, usando el principio de cita. Cuando un proceso 
ejecuta un SEND, la capa más baja del kemel verifica si el destino está esperando un mensaje del emisor 
(o de cualquier (ANY) emisor). Si así es, el mensaje se copia del buffer del emisor al buffer del receptor, y 
ambos procesos se marcan como ejecutables. Si el destino no está esperando un mensaje del emisor, éste 
se marca como bloqueado y se coloca en una cola de procesos que esperan para enviar al receptor. 

Cuando un proceso ejecuta un RECEIVE, el kemel verifica si hay algún proceso en cola tratando de 
enviar un mensaje al primero. Si así es, el mensaje se copia del emisor bloqueado al receptor, y ambos se 
marcan como ejecutables. Si no hay ningún proceso en cola tratando de enviarle un mensaje, el receptor se 
bloquea hasta que llega un mensaje. 

El código de alto nivel para la comunicación entre procesos se encuentra en proc.c. Al kemel 
corresponde traducir una interrupción de hardware o bien de software en un mensaje. La primera es 
generada por hardware y la segunda es la forma en que se comunica al kemel una solicitud de servicios 
del sistema, es decir, una llamada al sistema. Estos casos son lo bastante similares como para que se 
pudieran haber manejado con una sola función, pero resultó más eficiente crear dos funciones 
especializadas. 

Primero examinaremos interrupt (línea 6983), la cual es invocada por la rutina de servicio de 
interrupción de bajo nivel para un dispositivo después de recibirse una interrupción de hardware. La 
función de interrupt consiste en convertir la interrupción en un mensaje para la tarea que maneja el 
dispositivo interruptor, y por lo regular se efectúa muy poco procesamiento antes de llamar a interrupt. Por 
ejemplo, el manejador de interrupciones de bajo nivel completo para el controlador del disco duro consiste 
sólo en estas tres líneas: 

w STATUS = in_byte(w_wn—>base + REG STATUS); / acuse de interrupción / 
interrupt(WINCH ESTER); 
retum 1; 

Si no fúera necesario leer un puerto de E/S en el controlador del disco duro para obtener el 
estado, la llamada a interrupt podría haber estado en mpx386.x y no en at wini. c. Lo primero que hace 
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interrupt es verificar si ya se estaba atendiendo una interrupción cuando se recibió la interrupción actual; 
esto se hace examinando la variable k reenter (línea 6962). En este caso la interrupción actual se pone en 
cola e interrupt regresa. La interrupción actual será atendida después, cuando se invo que unhoid. La 
siguiente acción consiste en verificar si la tarea está o no esperando una interrupción (líneas 6978 a 6981). 
Si la tarea no está lista para recibir, se pone en 1 su bandera pintblocked—veremos más adelante que 
esto permite recuperar la interrupción perdida— y no se envía ningún mensaje. Si se pasa esta prueba, se 
envía el mensaje. El envío de un mensaje de HARDWARE a una tarea es sencillo, porque las tareas y el 
kemel se compilan en el mismo archivo y pueden acceder a las mismas áreas de datos. El código de las 
líneas 6989 a 6992 envía el mensaje llenando los campos de origen y tipo del buffer de mensaje de la tarea 
de destino, poniendo en O la bandera RECEIVING del destino y desbloqueando la tarea. Una vez que el 
mensaje está listo, se planifica la tarea de destino para que se ejecute. Estudiaremos la planificación con 
mayor detalle en la siguiente sección, pero el código de interrupt entre las líneas 6997 a 7003 nos da una 
idea de lo que veremos: éste es un sustituto en línea del procedimiento ready que se invoca para poner en 
cola un proceso. El código aquí es sencillo, ya que los mensajes que se originan en interrupciones sólo se 
envían a tareas, y por tanto no hay necesidad de determinar cuál de las tres colas de procesos debe 
modificarse. 

La siguiente función de proc.c es syscail, y tiene una función similar a la de interrupt: convierte 
una interrupción de software (la instrucción mt SYS386_ VECTOR con la que se inicia una llamada al 
sistema) en un mensaje. Sin embargo, como en este caso hay una variedad más amplia de posibles 
orígenes y destinos, y dado que la llamada puede requerir ya sea el envío o la recepción, o tanto el envío 
como la recepción, de un mensaje, sys .call tiene que efectuar más trabajo. Como suele suceder, esto 
implica que el código de sys cail es corto y sencillo, ya que efectúa casi todo su trabajo invocando otros 
procedimientos. La primera de estas llamadas es a isoksrc dest, una macro definida en proc. h (línea 
5172) que incorpora una macro más, isokprocn, también definida en proc.h (línea 5171). El efecto es que 
se verifica si el proceso especificado como origen o destino del mensaje es válido. En la línea 7026 se 
realiza una prueba similar, isuserp (otra macro definida en proc. h), para asegurarse de que si la llamada 
proviene de un proceso de usuario, éste está pidiendo enviar un mensaje y luego recibir una respuesta, ya 
que ésta es la única clase de llamada que pueden efectuar los procesos de usuario. Tales errores son poco 
probables, pero es fácil realizar las pruebas, ya que en última instancia se compilan para producir código 
que realiza comparaciones con enteros pequeños. En este nivel más básico del sistema operativo es 
aconsejable tratar de detectar incluso los errores más inverosímiles. Es probable que este código se ejecute 
muchas veces durante cada segundo que está activo el sistema de computa dora en el que se ejecuta. 

Por último, si la llamada requiere enviar un mensaje, se invoca minisend (línea 7031), y si es 
necesario recibir un mensaje, se invoca minirec (línea 7039). Estas fúnciones son el corazón del 
mecanismo normal de transferencia de mensajes de MINIX y conviene estudiarlos con detenimiento. 

Mini send (línea 7045) tiene tres parámetros, el invocador, el proceso al que se enviará el 
mensaje y un apuntador al buffer donde está el mensaje. Esta función realiza varias pruebas. 
Primero, se asegura de que los procesos de usuario sólo traten de enviar mensajes al FS o al MM. 
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En la línea 7060 se prueba el parámetro caller_ptr con la macro isuserp para determinar si el invocador es 
un proceso de usuario, y el parámetro dest se prueba con una función similar, issysentn, para determinar si 
es FS oMM. Si la combinación no es una de las permitidas, minisend ter mi na con un error. 

A continuación se verifica que el destino del mensaje sea un proceso activo, no una ranura vacía de 
la tabla de procesos (línea 7062). En las líneas 7068 a 7073 mini send verifica si el mensaje cae por 
completo dentro del segmento de datos de usuario, el segmento de código o el espacio entre ellos. Si no es 
así, se devuelve un código de error. 

La siguiente prueba consiste en verificar si podría haber un bloqueo mutuo. En la línea 7079 hay 
una prueba para asegurarse de que el destino del mensaje no esté tratando de enviar un mensaje de vuelta 
al invocador. 

La prueba clave en mini send está en las líneas 7088 a 7090. Aquí se verifica si el destino está 
bloqueado en un RECE! VE examinando el bit RECEIVING del campo pj7ags de su entrada en la tabla de 
procesos. Si el destino está esperando, la siguiente pregunta es “ quién está esperando?” Si está esperando 
al emisor, o a cualquiera (ANY), se ejecuta CopyMess para copiar el mensaje, y el receptor se desbloquea 
poniendo en O su bit RECEIVING. CopyMess se define como una macro en la línea 6932. Esta función 
invoca la rutina en lenguaje ensamblador cpmess que está en klib386.s. 

Por otro lado, si el receptor no está bloqueado, o está bloqueado pero esperando un mensaje de 
alguien más, se ejecuta el código de las líneas 7098 a 7111 a fin de bloquear y poner en cola al emisor. 
Todos los procesos que desean enviar a un destino dado se colocan en una lista enlazada, y el campo 
p callerq del destino apunta a la entrada de la tabla de procesos que corresponde al proceso que está a la 
cabeza de la cola. El ejemplo de la Fig. 2-35(a) muestra lo que sucede cuando el proceso 3 no puede 
enviar al proceso 0. Si subsecuentemente el proceso 4 tampoco puede enviar al proceso 0, tenemos la 
situación de la Fig. 2-35(b). 
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Figura 2-35. Puesta en cola de procesos que tratan de enviar al proceso 0. 


Mini rec (línea 6119) es invocada por sys eali cuando su parámetro function es RECEIVE (recibir) 
o BOTH (ambas cosas). El ciclo de las líneas 7137 a 7151 examina todos los procesos que están 
en cola esperando para enviar al receptor, para ver si alguno de ellos es aceptable. Si se 
encuentra uno, el mensaje se copia del emisor al receptor; luego el emisor se desbloquea, se marca 
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como listo para ejecutarse y se quita de la cola de procesos que están tratando de enviar al receptor. 

Si no se encuentra un emisor apropiado, se verifica si la bandera pintblocked del proceso receptor 
indica que previamente se bloqueó una interrupción para este destino (línea 7154). Si así es, se construye 
un mensaje en este momento; puesto que los mensajes de HARDWARE no tienen más contenido que 
HARDWARE en el campo de origen y HARD INTen el campo de tipo, no hay necesidad de invocar 
CopyMess en este caso. 

Si no se encuentra una interrupción bloqueada, las direcciones de origen y de buffer del proceso se 
guardan en su entrada de la tabla de procesos y el proceso se marca como bloqueado poniendo en 1 su bit 
RECEIVING. La llamada a unready en la línea 7165 quita al receptor de la cola de procesos ejecutables 
del planificador. La llamada es condicional para evitar bloquear de inmediato el proceso si hay otro bit en 
1 en su pflags; puede haber una señal pendiente, y el proceso debería tener otra oportunidad de ejecutarse 
pronto para manejar la señal. 

La penúltima instrucción de mini rec (líneas 7171 y 7172) tiene que ver con la forma como se 
manejan las señales SIGINT SIGQUIT y SIGALARM generadas por el kemel. Cuando ocurre una de 
éstas, se envía un mensaje al administrador de memoria, si éste está esperando un mensaje de ANY. Si no, 
la señal se recuerda en el kemel hasta que el administrador de memoria por fin trata de recibir de ANY. 
Eso se prueba aquí y, si es necesario, se invoca inform para informarle de las señales pendientes. 


2.6.9 Planificación en MINIX 

MINIX emplea un algoritmo de planificación multinivel que sigue de cerca la estructura que se muestra en 
la Fig. 2-26. En esa figura vemos tareas de E/S en la capa 2, procesos de servidor en la capa 3 y procesos 
de usuario en la capa 4. El planificador mantiene tres colas de procesos ejecutables, una para cada capa, 
como se muestra en la Fig. 2-36. El arreglo rdy head tiene una entrada por cada cola, y cada entrada 
apunta al proceso que está a la cabeza de la cola correspondiente. De forma similar, rdytail es un arreglo 
cuyas entradas apuntan al último proceso de cada cola. Ambos arreglos se definen con la macro EXTERN 
en proc.h (líneas 5192 y 5193). 
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Figura 2-36. El planificador mantiene tres colas, una por cada nivel de prioridad 


Cada vez que se despierta un proceso bloqueado, se le anexa al final de su cola. La existencia del arreglo 
rdy tail hace eficiente la acción de agregar un proceso al final de una cola. Cuando un 
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proceso en ejecución se bloquea, o un proceso ejecutable es terminado por una señal, ese proceso se quita 
de las colas del planificador. Sólo se ponen en cola los procesos ejecutables. 

Dadas las estructuras de cola que acabamos de describir, el algoritmo de planificación es sencillo: 
encontrar la cola con más alta prioridad que no está vacía y escoger el proceso que está a la cabeza de esa 
cola. Si todas las colas están vacías, se ejecuta la rutina de “marcha en vacío”. En la Fig. 2-36 TASKQ 
tiene la más alta prioridad. El código de planificación está en proc.c. La cola se escoge en pick_ proc 
(línea 7179). La tarea principal de esta función es establecer proc_ptr. Cualquier cambio a las colas que 
pudiera afectar la selección del siguiente proceso por ejecutar requiere una nueva invocación de pick_ 
proc. Siempre que el proceso en curso se bloquea, se invoca pick_proc para replanificar la CPU. 

Pick_proc es sencilla. Flay una prueba para cada cola. Primero se prueba TASK Q, y si un proceso 
de esta cola está listo, pick_proc establece proc_ptr y regresa de inmediato. A continuación se prueba 
SERVERQ y, otra vez, si hay un proceso listo pick_ proc establece proc_ptr y regresa. Si hay un proceso 
listo en la cola USER.Q, se modifica bill_ptr a fin de cobrar al proceso de usuario el tiempo de CPU que 
está a punto de concedérsele (línea 7198). Esto asegura que se cobre al último proceso de usuario 
ejecutado el trabajo realizado a su nombre por el sistema. Si ninguna de las colas tiene una tarea lista, la 
línea 7204 transfiere la facturación al proceso IDLE y lo planifica. El proceso escogido para ejecutarse no 
se quita de la cola en que está por el mero hecho de haber sido seleccionado. 

Los procedimientos ready (línea 7210) y unready (línea 7258) se invocan para ingresar un proceso 
ejecutable en su cola y quitar de su cola un proceso que ya no es ejecutable, respectiva mente. Ready se 
invoca tanto desde mini send como desde minirec, como hemos visto. También podría haberse llamado 
desde interrupt, pero en aras de agilizar el procesamiento de interrupciones su equivalente funcional se 
incluyó en interrupt como código en línea. Ready manipula una de las tres colas de procesos, agregando 
directamente el proceso al final de la cola apropiada. 

Unready también manipula las colas. Normalmente, el proceso que quita está a la cabeza de su cola, 
ya que un proceso necesita estar ejecutándose para poder bloquearse. En tal caso unready invocapick_proc 
antes de regresar, como por ejemplo en la línea 7293. Un proceso de usuario que no se está ejecutando 
también puede dejar de estar listo si se le envía una señal, y si el proceso está a la cabeza de una de las 
colas se busca en USERQ, eliminándose si se encuentra. 

Aunque la mayor parte de las decisiones de planificación se toman cuando un proceso se bloquea o 
desbloquea, también debe efectuarse planificación cuando la tarea del reloj se da cuenta de que el proceso 
de usuario actual excedió su cuanto. En este caso la tarea del reloj invoca sched (línea 7311) para pasar el 
proceso que está a la cabeza de USER Q al final de esa cola. Este algoritmo hace que los procesos de 
usuario se ejecuten por round robín simple. El sistema de archivos, el administrador de memoria y las 
tareas de E/S nunca se colocan al final de sus colas por haberse estado ejecutando durante demasiado 
tiempo; se confía en que funcionarán correctamente y se bloquearán después de haber terminado su 
trabajo. 

Hay unas cuantas rutinas más en proc.c que apoyan la planificación de procesos. Cinco de 
ellas, lockminisend, lock_pick_proc, lockready, lockunready y lock sched, establecen 
un candado, usando la variable switching antes de invocar la función correspondiente, y 
liberan el candado al completar su trabajo. La última función de este archivo, unhoid (línea 7400), se 
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mencionó cuando explicamos restart en mpx386.s. Unhoid procesa cíclicamente la cola de interrupciones 
detenidas, invocando interrupt para cada una, a fin de convertir todas las interrupciones pendientes en 
mensajes antes de que se permita a otro proceso ejecutarse. 

En síntesis, el algoritmo de planificación mantiene tres colas de prioridad, una para las tareas de E/S, 
otra para los procesos de servidor y otra para los procesos de usuario. Siempre se escoge para ejecutarse a 
continuación el primer proceso de la cola de más alta prioridad. Siempre se permite a las tareas y los 
servidores ejecutarse hasta bloquearse, pero la tarea del reloj vigila el tiempo utilizado por los procesos de 
usuario. Si un proceso de usuario agota su cuanto, se coloca al final de la cola, implementando así una 
planificación round robín simple entre los procesos de usuario en competencia. 


2.6.10 Apoyo de kernel dependiente del hardware 

Hay varias funciones de C que dependen en gran medida del hardware. Con objeto de facilitar el traslado 
de MINIX a otros sistemas, esas funciones se han segregado en los archivos que veremos en esta sección, 
exception.c, Í8259.C y protectc, en lugar de incluirse en los archivos en los que está el código de más alto 
nivel al que apoyan. 

Exception.c contiene el manejador de excepciones, exception (línea 7512) que es invocado (como 
exception) por la parte de lenguaje de ensamblador del código de manejo de excepciones de mpx386.s. 
Las excepciones que se originan en procesos de usuario se convierten en señales. Se espera que los 
usuarios cometan errores en sus propios programas, pero una excepción que se origina en el sistema 
operativo indica que algo anda en verdad mal y causa un pánico. El arreglo ex data (líneas 7522 a 7540) 
determina el mensaje de error que se exhibirá en caso de pánico, o la señal que se enviará a un proceso de 
usuario para cada excepción. Los primeros procesadores Intel no generan todas las excepciones, y el tercer 
campo de cada entrada indica el modelo de procesador mínimo que puede generar cada una. Este arreglo 
ofrece un resumen interesante de la evolución de la familia de procesadores Intel en la que se implemento 
MINIX. En la línea 7563 se exhibe un mensaje alterno si se produce un pánico por una interrupción que 
no se esperaría del procesador que se está usando. 

Las tres funciones de Í8259. c se usan durante la inícialización del sistema para asignar valores 
iniciales a los chips controladores de interrupciones Intel 8259. Intrinit (línea 7621) inicializa los 
controladores escribiendo datos en varias direcciones de puertos. En unas cuantas líneas se prueba una 
variable derivada de los parámetros de arranque para dar cabida a diferentes modelos de computadoras. 
Por ejemplo, en la línea 7637 se escribe en el primer puerto, con dirección determinada por el tipo de 
hardware. En la línea 7638, y otra vez en la línea 7644, se prueba el parámetro mine, escribiéndose en el 
puerto un valor apropiado ya sea para MINIX o para el BIOS ROM. Al salir de MINIX se puede invocar 
intr init para restaurar los vectores de BIOS, efectuándose así una salida digna al monitor 
de arranque. Mine selecciona el modo que se usará. Para entender perfectamente lo que 
está sucediendo aquí sería necesario estudiar la documentación del circuito integrado 
8259, así que no entraremos en detalles. Señalaremos que la llamada outbyte de 
la línea 7642 hace que el controlador maestro deje de responder a cualquier entrada excepto la que 
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proviene del esclavo, y la operación similar de la línea 7648 inhibe la respuesta del esclavo a sus entradas. 
Además, la última línea de la función precarga la dirección de spurious irq, la siguiente función del 
archivo (línea 7657), en cada ranura de irq jable. Esto asegura que cualquier jwciTuppión generada antes 
de que se instalen los manejadores reales no cause ningún daño. 

La última fúnción de Í8259 c es put jrq_handler (linea 7673) Durante la inicialización cada que debe 
responder a una interrupción invoca esta fúnción para colocar la dirección de su p manejador en la tabla de 
interrupciones sobreescribiendo la dirección de spurlouszrq 

Protect.c contiene rutinas relacionadas con la operación en modo protegido de los procesadores tel. 
La tabla de descriptores globales (GDT), las tablas de descriptores locales (LDT) y la Iála de descriptores 
de interrupciones (IDT) todas situadas en la memoria, proporcionan acceso protegido a los recursos del 
sistema. Registros especiales dentro de la CPU apuntan a la GDT y a s IDT, y las entradas de la GDT 
apuntan a las LDT. La GDT está accesible para todos los procesos y contiene descriptores de segmento de 
las regiones de memoria utilizadas por el sistema operativo. Normalmente hay una LDT para cada 
proceso, y contiene descriptores de segmento para las regiones de memoria que el proceso usa. Los 
descriptores son estructuras de ocho bytes con varios componentes, pero las partes más importantes de un 
descriptor de segmento son los campos que describen la dirección base y el límite de una región de 
memoria. La IDT también se compone de descriptores de ocho bytes, siendo la parte más importante la 
dirección del código que se ejecutará cuando se active la interrupción correspondiente. 

Prot init (línea 7767) es invocada por start.c para establecer la GDT en las líneas 7828 a 7845. El 
IBM PC BIOS requiere que esta tabla esté ordenada de cierta manera, y todos los índices para acceder a 
ella se definen en protect. h. En la tabla de procesos se asigna espacio para una LDT para cada proceso. 
Cada LDT contiene dos descriptores, para un segmento de código y uno de datos (recuerde que aquí 
estamos hablando de segmentos definidos por el hardware; éstos no son los mismos segmentos 
administrados por el sistema operativo, el cual considera que el segmento de datos definido por el 
hardware está dividido en segmentos de datos y de pila). En las líneas 7851 a 7857 se construyen en la 
GDT descriptores para cada LDT. Las fúnciones initdataseg e init codeseg realmente construyen estos 
descriptores. Las entradas de las LDT mismas se inicializan cuando se modifica el mapa de memoria de 
un proceso (es decir, cuando se emite una llamada al sistema EXEC). 

Otra estructura de datos del procesador que requiere inicialización es el segmento de estado de 
tareas (TSS). La estructura se define al principio de este archivo (líneas 7725 a 7753) y proporciona 
espacio para almacenar registros del procesador y otra información que debe guardarse cuando se efectúa 
una conmutación de tarea. MINIX usa sólo los campos que definen dónde debe construirse una nueva pila 
cuando ocurre una interrupción. La llamada a init dataseg de la línea 7867 asegura que se le podrá 
encontrar usando la GDT. 

Si queremos entender cómo fúnciona MINIX en el nivel más bajo, tal vez la cosa más importante 
sea entender la forma en que las excepciones, interrupciones de hardware o instrucciones mt < nnn > dan 
pie a la ejecución de las distintas secciones de código que se han escrito para atenderlas. Esto se 
logra por medio de la tabla de descriptores de puertas de interrupciones. El compilador inicializa 
el arreglo gate table (líneas 7786 a 7818) con las direcciones de las rutinas que manejan 
las excepciones e interrupciones de hardware y luego se usa este arreglo en el ciclo de las líneas 7873 
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a 7877 para inicializar una buena parte de la tabla mencionada, usando llamadas a la función intgate. Los 
vectores restantes, SYS_VECTOR, SYS386_VECTOR y LE VELO_VECTOR, requieren niveles de 
privilegio distintos y se inicializan después del ciclo. 

Existen buenas razones para estructurar los datos de la forma como se hace en los descriptores, 
basándose en detalles del hardware y en la necesidad de mantener la compatibilidad entre los procesadores 
avanzados y el procesador 286 de 16 bits. Por fortuna, normalmente podemos dejar estos detalles a los 
diseñadores de procesadores de Intel. En general, el lenguaje C nos permite evitar los detalles. Sin 
embargo, al implementar un sistema operativo real es necesario enfrentar los detalles en algún momento. 
En la Fig. 2-37 se muestra la estructura intema de un tipo de descriptor de segmento. Observe que la 
dirección base, a las que los programas en C pueden referirse con un entero sin signo de 32 bits, se divide 
en tres partes, dos de las cuales están separadas por varias cantidades de 1, 2 y 4 bits. El límite es una 
cantidad de 20 bits almacenada como un trozo de 16 bits y uno de 4 bits. Este límite se interpreta ya sea 
como ul ne bytes o como un número de páginas de 4096 bytes, con base en el valor del bit G (de 
granularidad). Otros descriptores, como los que se usan para especificar la forma de manejar las 
interrupciones, tienen estructuras diferentes, pero igualmente complejas. Analizaremos tales estructuras 
con mayor detalle en el capítulo 4. 
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Figura 2-37. Formato de un descriptor de segmento Intel. 


La mayor parte de las otras fruiciones definidas en protec. c sirven para realizar la conversión 
entre las variables empleadas en los programas en C y las formas más bien feas que esos datos adoptan en 
los descriptores legibles por la máquina como el de la Fig. 2-37. Initcodeseg (línea 7889) e initdataseg 
(línea 7906) tienen un fúncionamiento similar y sirven para convertir los parámetros que les son pasados 
en descriptores de segmentos. Cada una, a su vez, invoca a la siguiente fúnción, sdesc (línea 7922) para 
completar el trabajo. Aquí es donde se manejan los desagradables detalles de la estructura de la Fig. 2-37. 
Init codeseg e init data seg no sólo se utilizan durante la inicialización del sistema. Además, son 
invocadas por la tarea del sistema cada vez que se inicia un nuevo proceso, a fin de asignar los segmentos 
de memoria correctos que el proceso usará. Seg2phys (línea 7947), que sólo se invoca desde start.c, 
realiza una operación que es el inverso de la de sdesc, extraer de un descriptor de segmento la dirección 
base de un segmento, ¡nt gate (línea 7969) realiza una labor similar a la de init codeseg e init dataseg, 
construyen do entradas para la tabla de descriptores de interrupciones. 
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La última función de protect.c, enableiop (línea 7988) tiene una misión subrepticia. Ya hemos 
señalado varias veces que una de las funciones del sistema operativo es proteger los recursos del sistema, 
y una forma en que MINIX hace esto consiste en usar niveles de privilegio para que los procesos de 
usuario no puedan utilizar ciertos tipos de instrucciones. Sin embargo, también se pretende que MINIX se 
utilice en sistemas pequeños, que con toda probabilidad sólo tendrán un usuario o tal vez unos cuantos 
usuarios de confianza. En un sistema así, un usuario bien podría querer escribir un programa de aplicación 
que tenga acceso a los puertos de E/S, por ejemplo, pera usarlos en la obtención de datos científicos. El 
sistema de archivos tiene incorporado un pequeño secreto: si se abren los archivos Idevimem o 
/dev/kmem, la tarea de memoria invoca enable iop, la cual cambia el nivel de privilegio de las 
operaciones de E/S, permitiendo al proceso actual ejecutar instrucciones que leen los puertos de E/S y 
escriben en ellos. La descripción del propósito de la función es más complicada que la función misma, que 
simplemente pone en 1 dos bits de la palabra en la entrada del soporte de pila del proceso invocador que 
se cargará en el registro de estado de la CPU la próxima vez que el proceso se ejecute. No se necesita otra 
función que revierta esta acción, pues sólo se aplicará al proceso invocador. 


2,6.11 Rutinas de utilidad y biblioteca del kernel 

Por último, el kemel tiene una biblioteca de fúnciones de apoyo escritas en lenguaje ensamblador, que se 
incluyen compilando klib.s, y unos cuantos programas de utilidad, escritos en C, en el archivo misc.c. 
Examinemos primero los archivos en lenguaje ensamblador. Klib.s (línea 8000) es un archivo corto 
similar a mpx.s, que selecciona la versión apropiada, específica para la máquina, con base en la definición 
de WORD SIZE (tamaño de palabra). El código que analizaremos está en kllb386.s (línea 8100), y 
contiene unas dos docenas de rutinas de utilidad escritas en lenguaje ensamblador ya sea por razones de 
eficiencia o porque no es posible escribirlas en C. 

Monitor (línea 8166) permite regresar al monitor de arranque. Desde el punto de vista del 
monitor de arranque, todo MINIX no es más que una subrutina, y cuando se inicia MINIX se deja una 
dirección de retomo al monitor en la pila de éste. Lo único que tiene que hacer monitor es restaurar los 
diversos selectores de segmento y el apuntador a la pila que se guardó cuando MINIX se inició, y luego 
regresar como de cualquier otra subrutina. 

La siguiente fúnción, checkmem (línea 8198), se usa en el momento de iniciarse MINIX para 
determinar el tamaño de un bloque de memoria. Esta función realiza una prueba sencilla con cada 
decimosexto byte, usando dos patrones que prueban cada bit con valores tanto “0” como “I”. 

Aunque podría haberse usado _phys_copy (véase más adelante) para copiar mensajes, se ha 
suministrado cpmess (línea 8243) para ese fin, pues es un procedimiento especializado más rápido. 
Este procedimiento se invoca con 

cp_mess(source, src clicks, src offset, dest_clícks,dest_offset); 

donde source es el número de proceso del emisor, que se copia en el campo msource del buffer 
del receptor. Las direcciones tanto de origen como de destino se especifican dando un número 
de click, por lo regular la base del segmento que contiene el buffer, y un desplazamiento respecto a 
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ese click. Esta forma de especificar el origen y el destino es más eficiente que las direcciones de 32 bits 
utilizadas por _phys_copy. 

Exit, — exit y-exit (líneas 8283 a 8285) se definen porque algunas rutinas de biblioteca que 

podrían usarse para compilar MINIX hacen llamadas a la función C estándar exit. Salir del kemel no es un 
concepto significativo, pues no hay adonde ir. La solución aquí es habilitar las interrupciones y entrar en 
un ciclo infinito. Tarde o temprano una operación de E/S o el reloj causará una interrupción y se reanudará 
el funcionamiento normal del sistema. El punto de entrada para main (línea 8289) es otro intento de 
manejar una acción del compilador que, si bien podría tener sentido durante la compilación de un 
programa de usuario, no tiene ningún objeto en el kemel. Esta función apunta a una instrucción ret 
(regresar de subrutina) de lenguaje ensamblador. 

jn byte (línea 8300), _in (línea 8314), out byte (línea 8328) y out word (línea 8342) 
proporcionan acceso a puertos de E/S, que en el hardware Intel ocupan un espacio de direcciones distinto 
del de la memoria y usan instrucciones diferentes de las que leen y escriben en la memoria. Portjead 
(línea 8359), _portjead_byte (línea 8386), _port_write (línea 8412) y port_writej,yte (línea 8439) se 
encargan de transferir bloques de datos entre puertos de E/S y la memoria; se usan primordialmente para 
transferencias desde y hacia el disco que deben efectuarse con mucha mayor rapidez que la que es posible 
con las otras llamadas de E/S. Las versiones de bytes leen 8 bits en lugar de 16 bits en cada operación, a 
fin de manejar dispositivos periféricos antiguos de 8 bits. 

De vez en cuando, una tarea necesitará inhabilitar todas las interrupciones de la CPU 
temporalmente; esto lo hace invocando jock (línea 8462). Cuando ya puedan habilitarse otra vez las 
interrupciones, la tarea puede invocar unlock (línea 8474) para hacerlo. Una sola instrucción de máquina 
realiza cada una de estas operaciones. En contraste, el código para Enablejrq (línea 8488) y disablejrq 
(línea 8521) es más complicado. Estas funciones operan en el nivel de los chips controladores de 
interrupciones para habilitar e inhabilitar interrupciones de hardware individuales. 

Phys copy (línea 8564) se invoca en C con 
phys_copy(sourceaddress, destination address, bytes); 

y copia un bloque de datos de cualquier lugar de la memoria física a cualquier otro lugar. Ambas 
direcciones son absolutas, es decir, la dirección O realmente se refiere al primer byte de todo el espacio de 
direcciones, y los tres parámetros son longs sin signo. 

Las siguientes dos funciones cortas son muy específicas para los procesadores Intel. Memrdw 
(línea 8608) devuelve una palabra de 16 bits de cualquier lugar de la memoria. El resultado se llena con 
ceros dentro del registro eax de 32 bits. La función reset (línea 8623) restablece el procesador cargando 
el registro de la tabla de descriptores de interrupciones del procesador con un apuntador nulo y ejecutando 
a continuación una interrupción de software. Esto tiene el mismo efecto que un “reset” de hardware. 


Las dos siguientes rutinas apoyan la exhibición en pantalla y son utilizadas por la tarea de la 
consola. Memvidcopy (línea 8643) copia una cadena de palabras que contienen bytes 
altemos de caracteres y atributos desde la región de memoria del kemel a la memoria de 
pantalla, Vid vid copy (línea 8696) copia un bloque dentro de la memoria de video misma. Esto es un 
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poco más complicado, ya que el bloque de destino y el de origen pueden traslaparse, y la dirección del 
traslado es importante. 

La última función de este archivo es levelO (línea 8773), que permite a las tareas tener el nivel de 
permisos más privilegiado, el nivel cero, en caso necesario. Esta función se usa para cosas tales como 
restablecer la CPU o acceder a las rutinas del ROM BIOS de la PC. 

Las rutinas de utilidad en C contenidas en misc.c son especializadas. Meminit (línea 8820) sólo es 
invocada por main, cuando se inicia MINIX. En una computadora compatible con la IBM PC puede haber 
dos o tres regiones de memoria no continuas. El BIOS informa al monitor de arranque el tamaño del 
intervalo más bajo, que los usuarios de PC conocen como memoria “ordinaria”, y el del intervalo de 
memoria que comienza arriba del área de ROM (memoria “extendida”). A su vez, el monitor pasa los 
valores como parámetros de arranque, que son interpretados por cstart y se escriben en lowmemsize y 
extmemsize durante el arranque. La tercera región es la memoria “sombra”, en la que puede copiarse el 
BIOS ROM para mejorar el rendimiento, ya que la memoria ROM normalmente es más lenta que la RAM. 
Puesto que MINIX normalmente no usa el BIOS, mem init trata de localizar esta memoria y agregarla a la 
reserva de memoria disponible para su uso. Esto lo hace invocando checkmem para probar la región de 
memoria donde a veces se puede encontrar la memoria en cuestión. 

La siguiente rutina, env_parse (línea 8865) también se usa durante el inicio del sistema. El monitor 
de arranque puede pasar cadenas arbitrarias como “DPETHO=300: 10” a MINIX en los parámetros de 
arranque. Env_parse trata de encontrar una cadena cuyo primer campo coincida con su primer argumento, 
env, y luego extraer el campo solicitado. Los comentarios del código explican el uso de la función, que se 
proporciona principalmente para ayudar al usuario que desea agregar nuevos controladores que tal vez 
requieran parámetros. El ejemplo “DPETHO” se usa para pasar información de configuración a un 
adaptador de Ethernet cuando se incluye apoyo de red durante la compilación de MINIX. 

Las últimas dos rutinas que veremos en este capítulo son bad assertion (línea 8935) y badcompare 
(línea 8947). Éstas sólo se compilan si la macro DEBUG se define como TRUE, y apoyan las macros de 
asserth. Aunque no se hace referencia a ellas en ninguna parte del código que describimos en el texto, 
pueden ser de utilidad durante la depuración para el lector que desee crear una versión modificada de 
MINIX. 


2,7 RESUMEN 

A fin de ocultar los efectos de las interrupciones, los sistemas operativos ofrecen un modelo conceptual 
que consiste en procesos secuenciales que se ejecutan en paralelo. Los procesos pueden comunicarse entre 
sí mediante primitivas de comunicación entre procesos, como son los semáforos, monitores o mensajes. 
Estas primitivas aseguran que dos procesos nunca estarán en sus regiones críticas al mismo tiempo. Un 
proceso puede estar ejecutándose, listo o bloqueado, y puede cambiar de estado cuando él u otro proceso 
ejecuta una primitiva de comunicación entre procesos. 

Se pueden usar las primitivas de comunicación entre procesos para resolver problemas tales como el 
de productor-consumidor, cena de filósofos, lector-escritor y peluquero dormido. Incluso 
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con estas primitivas, debe tenerse cuidado para evitar errores y bloqueos. Se conocen muchos algoritmos 
de planificación, incluidos round robin, planificación por prioridad, colas multinivel y planificadores 
controlados por políticas. 

MINIX maneja el concepto de procesos y proporciona mensajes para la comunicación entre 
procesos. Los mensajes no se guardan en buffers, así que un SEND sólo tiene éxito cuando el receptor lo 
está esperando. De forma similar, un RECEIVE sólo tiene éxito cuando está disponible un mensaje. Si 
cualquiera de estas operaciones no tiene éxito, el invocador se bloquea. 

Cuando ocurre una interrupción, el nivel más bajo del kemel crea y envía un mensaje a la tarea 
asociada al dispositivo interruptor. Por ejemplo, la tarea de disco invoca receive y se bloquea después de 
escribir un comando al hardware controlador del disco pidiéndole que lea un bloque de datos. Una vez que 
los datos están listos, el hardware controlador hace que ocurra una interrupción. A continuación, el 
software de bajo nivel elabora un mensaje para la tarea de disco y la marca como ejecutable. Cuando el 
planificador escoge la tarea de disco para que se ejecute, obtiene y procesa el mensaje. El manejador de 
interrupciones también puede realizar cierto trabajo directamente, como cuando una interrupción de reloj 
actualiza la hora. 

Después de una interrupción puede haber conmutación de tareas. Cuando un proceso se 
interrumpe, se crea una pila dentro de la entrada correspondiente a ese proceso en la tabla de procesos, y 
en esa pila se coloca toda la información necesaria para reiniciar el proceso. Cualquier proceso puede 
reiniciarse ajustando el apuntador de pila de modo que apunte a su entrada en la tabla de procesos e 
iniciando una secuencia de instrucciones para restaurar los registros de la CPU, que culmina con una 
instrucción iretd. El planificador decide cuál entrada de la tabla de procesos se colocará en el apuntador a 
la pila. 

También ocurren interrupciones mi entras se está ejecutando el kemel mismo. La CPU detecta 
esto, y se usa la pila del kemel en lugar de una pila dentro de la tabla de procesos. Esto permite que 
ocurran interrupciones anidadas, y cuando termina una rutina de servicio de interrupción posterior, puede 
llegar a su término la que está abajo de ella. Una vez atendidas todas las interrupciones, se reinicia un 
proceso. 

El algoritmo de planificación de MINIX usa tres colas de prioridad: la más alta para tareas, la 
siguiente para el sistema de archivos, el administrador de memoria y otros servidores, silos hay, y la más 
baja para los procesos de usuario. Estos últimos se ejecutan por round robin durante un cuanto a la vez; 
todos los demás se ejecutan hasta bloquearse o ser desalojados. 


PROBLEMAS 


1. Suponga que va a diseñar una arquitectura de computadora avanzada que realizará la conmutación de 
procesos por hardware, en lugar d>e-tenerinterrupciones. ¿Qué información necesitaría la CPU? Describa 
cómo podría funcionar la conmutación de procesos por hardware. 

2. En todas las computadoras actuales, al menos una parte de los manejadores de interrupciones se escribe 
en lenguaje ensamblador. ¿Por qué? 
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3. En el texto se dijo que el modelo de la Fig. 2-6(a) no es apropiado para un servidor de archivos que usa 
un caché en memoria. ¿Por qué no? ¿Podría cada proceso tener su propio caché? 

4. En un sistema con hilos, ¿hay una pila por hilo o una pila por proceso? Explique. 

5. ¿Qué es una condición de competencia? 

6. Escriba un guión (script) de shell que produzca un archivo de números secuenciales leyendo el último 
número del archivo, sumándole 1 y anexándolo al final del archivo. Ejecute un ejemplar del guión en 
segundo plano y otro en primer plano, con ambos accediendo al mismo archivo. ¿Cuánto tiempo tarda en 
manifestarse una condición de competencia? ¿Cuál es la sección crítica? Modifique el guión a modo de 
prevenir la competencia (sugerencia: use 

In file file.Iock 


para poner un candado al archivo de datos). 

7. Una ins trucción como 


ln file file.Iock 


¿es un mecanismo de candado efectivo para un programa de usuario como los guiones empleados en 
el problema anterior? ¿Por qué sí o por qué no? 

8. La solución de espera activa usando la variable tum (Fig. 2-8) ¿funciona cuando los dos procesos se 
están ejecutando en un multiprocesador de memoria compartida, es decir, dos CPU que comparten la 
misma memoria? 


9. Considere una computadora que no cuenta con la instrucción TEST AND SET LOCK pero sí tiene una 
instrucción que intercambia el contenido de un registro y una palabra de memoria en una sola acción 
indivisible. ¿Se puede usar esta instrucción para escribir una rutina enter region como la de la Fig. 2-10? 

10. Bosqueje la forma en que un sistema operativo que puede inhabilitar interrupciones podría 
implementar semáforos. 

11. Muestre cómo pueden implementarse semáforos contadores (es decir, semáforos capaces de contener 
un valor arbitrariamente grande) usando sólo semáforos binarios e instrucciones de máquina ordinarias, 

12. En la sección 2.2.4 se describió una situación con un proceso de alta prioridad, H, y uno de baja 
prioridad, L, que condujo a la repetición infinita de H. ¿Ocurre el mismo problema si se usa planificación 
round robín en vez de planificación por prioridad? Explique. 

13. La sincronización dentro de los monitores se logra usando variables de condición y dos operaciones 
especiales, WA y SIGNAL. Una forma más general de sincronización se lograría con la ayuda de una sola 
primitiva, WAITUNTIL (esperar hasta) que tuviera un predicado booleano arbitrario como parámetro. 
Así, podríamos escribir, por ejemplo, 

WAITUNTIL x<0 o y + z<n 

La primitiva SIGNAL ya no se necesitaría. Queda claro que este esquema es más general que el de 
Hoare o el de Brinch Hansen, y sin embargo no se usa. ¿Por qué no? (Sugerencia: piense en la 
implementación.) 

14. Un restaurante de “comida rápida” tiene cuatro tipos de e (1) receptores de pedidos, que toman los 
pedidos de los clientes; (2) cocineros, que preparan la comida; (3) especialistas en empacado, que meten la 
comida en bolsas; y (4) cajeros, que entregan las bolsas a los clientes y reciben su dinero. Cada empleado 
puede considerarse como un proceso secuencial en comunicación. ¿Qué forma de comunicación entre 
procesos utilizan? Relacione este modelo con los procesos en MINIX. 
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15. Suponga que tenemos un sistema de transferencia de mensajes que usa buzones. Al enviar mensajes a 
un buzón lleno o tratar de recibirlos de un buzón vacío, un proceso no se bloquea, sino que recibe de 
vuelta un código de error. El proceso responde al código de error intentándolo de nuevo, una y otra vez, 
hasta que tiene éxito. ¿Da este esquema lugar a condiciones de competencia? 

16. En la solución al problema de la cena de filósofos (Fig. 2-20), ¿por qué se asigna HUNGRY 
(hambriento) a la variable de estado en el procedimiento takeforks (tomar tenedores)? 

17. Considere el procedimiento put forks (poner tenedores) de la Fig. 2-20. Suponga que se asigna el 
valor THINKING (pensando) a la variable de estado State después de las dos llamadas a test (probar), en 
lugar de antes. ¿Cómo afectaría este cambio la solución para el caso de tres filósofos? ¿Y para 100 
filósofos? 

18. El problema de lectores y escritores se puede formular de varias formas en lo tocante a cuál categoría 
de procesos puede iniciarse y cuándo. Describa minuciosamente tres variaciones diferentes del problema, 
cada una de las cuales favorece (o no favorece) alguna categoría de procesos. Para cada variación, 
explique qué sucede cuando un lector o un escritor queda listo para acceder a la base de datos, y qué 
sucede cuando un proceso termina de usar la base de datos. 

19. Las computadoras CDC 6600 podían manejar hasta 10 procesos de E/S simultáneamente usando una 
forma interesante de planificación round robín llamada compartición de procesador. Ocurría una 
conmutación de proceso después de cada instrucción, de modo que la instrucción 1 provenía del proceso 
2, la instrucción 2 provenía del proceso 2, etc. La conmutación de procesos se efectuaba mediante un 
hardware especial, y el gasto extra era cero. Si un proceso necesitaba T segundos para llegar a su fin en la 
ausencia de competidores, ¿cuánto tiempo necesitaría si se usara compartición de procesador con n 
procesos? 

20. Los planificadores round robín normalmente mantienen una lista de todos los procesos ejecutables, y 
cada proceso aparece una y sólo una vez en la lista. ¿Qué sucedería si un proceso ocurriera dos veces en la 
lista? ¿Puede usted pensar en alguna razón para permitir esto? 

21. Mediciones realizadas en cierto sistema indican que, en promedio, un proceso se ejecuta durante un 
tiempo T antes de bloquearse en espera de E/S. Una conmutación de procesos requiere un tiempo 5, que 
efectivamente se desperdicia (gasto extra). Para planificación round robín con cuanto Q, deduzca una 
fórmula para la eficiencia de la CPU en cada uno de los siguientes casos: 

(a) Q = oo 

(b) Q > T 

(c) S < Q < T 

(d) Q = S 

(e) Q casi O 

22. Cinco trabajos están esperando para ejecutarse. Sus tiempos de ejecución esperados son 9, 6, 3, 5 y X. 
¿En qué orden deben ejecutarse sise desea minimizar el tiempo medio de respuesta? (Su respuesta 
dependerá de X.) 

23. Cinco trabajos por lotes, A a E, llegan a un centro de cómputo casi al mismo tiempo, y tienen tiempos 
de ejecución estimados de 10, 6, 2, 4 y 8 mi nutos. Sus prioridades (determinadas externamente) son 3, 5, 
2, 1 y 4, respectivamente, siendo 5 la prioridad más alta. Para cada uno de los siguientes algoritmos de 
planificación, determine el tiempo de retomo medio de los procesos. Ignore el gasto extra por 
conmutación de procesos. 
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(a) Round robin. 

(b) Planificación por prioridad. 

(c) Primero que llega, primero que se atiende (ejecutados en el orden 10, 6, 2, 4, 8). 

(d) El primer trabajo más corto. 

Para (a), suponga que el sistema está multiprogramado, y que cada trabajo recibe una parte 
equitativa del tiempo de CPU. Para (b) a (d), suponga que sólo se ejecuta un trabajo a la vez, hasta 
terminar. Todos los trabajos están limitados únicamente por CPU. 

24. Un proceso que se ejecuta en CTSS necesita 30 cuantos para llegar a su fin. ¿Cuántas veces debe 
intercambiarse a memoria, incluida la primera vez (antes de que se ejecute por primera vez)? 

25. Se está usando el algoritmo de maduración con a = 1/2 para predecir los tiempos de ejecución. Las 
cuatro ejecuciones anteriores, de la más antigua a la más reciente, tardaron 40, 20, 40 y 15 ms. Determine 
la predicción para la siguiente ejecución. 

26. Un sistema de tiempo real flexible tiene cuatro eventos periódicos con periodos de 50, 100, 200 y 250 
ms cada uno. Suponga que los cuatro eventos requieren 35, 20, 10 y x ms de tiempo de CPU, 
respectivamente. Determine el valor máximo de x para el cual el sistema es planificable. 

27. Explique por qué se usa comúnmente la planificación de dos niveles. 

28. Durante su ejecución, MINIX mantiene una variable proc_ptr que apunta a la entrada para el proceso 
actual en la tabla de procesos, ¿por qué? 

29. MINIX no guarda en buffers los mensajes. Explique por qué esta decisión de diseño causa problemas 
con las interrupciones del reloj y el teclado. 

30. Cuando se envía un mensaje a un proceso dormido en MINIX, se invoca el procedimiento ready para 
colocar ese proceso en la cola de planificación correcta. Lo primero que hace este procedimiento es 
inhabilitar las interrupciones. Explique. 

31. El procedimiento de MINIX minirec contiene un ciclo. Explique para qué sirve. 

32. En esencia, MINIX usa el método de planificación de la Fig. 2-23, con diferentes prioridades para las 
clases. La clase más baja (procesos de usuario) tiene planificación round robin, pero siempre se permite 
que las tareas y servidores se ejecuten hasta bloquearse. ¿Es posible que procesos de la clase más baja 
sufran inanición? ¿Por qué sí o por qué no? 

33. ¿Es MINIX apropiado para aplicaciones de tiempo real, como el registro de datos? Si no es así, ¿qué 
podría hacerse para que lo fuera? 

34. Suponga que tiene un sistema operativo que cuenta con semáforos. Implemente un sistema de 
mensajes. Escriba los procedimientos para enviar y recibir mensajes. 

35. Un estudiante de antropología con diplomado en ciencias de la computación se ha embarcado en un 
proyecto de investigación para determinar si es posible a babuinos africanos qué es un bloqueo mutuo. 
Localiza un cañón profundo y tiende una cuerda un lado a otro, de modo que los babuinos puedan cruzar 
el cañón colgándose de la cuerda y pasando un mano sobre la otra. Varios babuinos pueden cruzar al 
mismo tiempo, siempre que todos vayan en la misma dirección. Si en algún momento están en la cuerda al 
mismo tiempo babuinos que van hacia el este y otros que van hacia el oeste, ocurrirá un bloqueo (los 
babuinos quedarán atorados a la mitad) porque un babuino no puede pasar sobre otro mi entras 
cuelgan por encima del cañón. Si un babuino desea cruzar el cañón, debe verificar 
que ningún otro babuino esté cruzando actualmente en la dirección opuesta. Escriba un programa 
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usando semáforos que eviten los bloqueos. No se preocupe porque una serie de babuinos dirigidos hacia el 
este detenga indefinidamente a los babuinos que viajan hacia el oeste. 

36. Repita el problema anterior, pero ahora evite la inanición. Cuando un babuino que desea cruzar hacia 
el este llega a la cuerda y encuentra babuinos cruzando hacia el oeste, espera hasta que la cuerda está 
vacía, pero no se permite que más babuinos comiencen a cruzar hacia el oeste hasta que al menos un 
babuino haya cruzado en el otro sentido. 

37. Resuelva el problema de la cena de filósofos usando monitores en lugar de semáforos. 

38. Agregue código al kemel de MINIX para seguir la pista al número de mensajes enviados por el 
proceso (o tarea) i al proceso (o tarea) j. Exhiba en la pantalla esta matriz cuando se pulse la tecla F4. 

39. Modifique el planificador de MINIX de modo que lleve un registro de cuánto tiempo de CPU le ha 
sido concedido a cada proceso de usuario recientemente. Si ninguna tarea o servidor quiere ejecutarse, el 
planificador escogerá el proceso que ha utilizado menos la CPU. 

40. Rediseñe MINIX de modo que cada proceso tenga un campo de nivel de prioridad en su tabla de 
procesos que pueda servir para otorgar prioridades más altas o más bajas a procesos individuales. 

41. Modifique las macros hwintmaster y hwint slave de mpx386.s de modo que las operaciones que 
ahora ejecuta la función save se realicen en línea. Determine el costo en términos de tamaño del código. 
¿Puede usted medir el aumento en el rendimiento? 
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ENTRADA/SALIDA 


Una de las principales funciones de un sistema operativo es controlar todos los dispositivos de E/S 
(entrada/salida) de una computadora. El sistema operativo debe enviar comandos a los dispositivos, 
detectar interrupciones y manejar errores; también debe proveer una interfaz entre los dispositivos y el 
resto del sistema que sea sencilla y fácil de usar. Se debe tratar al máximo que la interfaz sea la misma 
para todos los dispositivos (independencia respecto al dispositivo). El código de E/S representa una parte 
significativa del sistema operativo total. La forma en que el sistema operativo administra la E/S es el tema 
de este capítulo. 

He aquí un bosquejo del capítulo. Primero examinaremos brevemente algunos de los principios del 
hardware de E/S, y luego estudiaremos el software de E/S en general. El software de E/S puede 
estructurarse en capas, cada una de las cuales tiene una tarea bien definida que realizar. Analizaremos 
estas capas para ver qué hacen y cómo se relacionan entre sí. 

A continuación viene una sección sobre los bloqueos mutuos. Definiremos éstos de forma precisa, 
indicaremos sus causas, presentaremos dos mód para analizarlos y estudiaremos algunos algoritmos para 
prevenir su incidencia. 

Después, revisaremos brevemente la E/S de MINIX. A continuación de la introducción, 
examinaremos cuatro dispositivos de E/S con detalle: el disco en RAM, el disco duro, el reloj y la 
terminal. Para cada dispositivo estudiaremos su hardware, software e implementación en MINIX. Por 
último, concluiremos el capítulo con una explicación corta de un pequeño componente de MINIX que se 
encuentra en la misma capa que las tareas de E/S pero que en sí no es una tarea de E/S. Este código 
proporciona algunos servicios al administrador de memoria y al sistema de archivos, como la obtención de 
bloques de datos de un proceso de usuario. 
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3.1 PRINCIPIOS DEL HARDWARE DE E/S 

Los puntos de vista respecto al hardware de E/S son muy distintos para cada persona, dependiendo del 
campo en el que trabaje. Los ingenieros eléctricos lo ven en términos de chips, alambres, fuentes de 
potencia, motores y todos los demás componentes físicos que constituyen el hardware. Los programadores 
tienen en cuenta la interfaz en relación con el software: los comandos que el hardware acepta, las 
funciones que realiza y los errores que puede informar. En este libro nos interesa la programación de los 
dispositivos de E/S, no su diseño, construcción ni mantenimiento, así que nuestra atención se limitará a la 
forma como el hardware se programa, no a cómo funciona internamente. No obstante, la programación de 
muchos dispositivos de E/S a menudo está íntimamente ligada con su funcionamiento interno. En las tres 
secciones que siguen presentaremos algunos antecedentes generales del hardware de E/S que pudieran 
tener relación con su programación. 


3.1.1 Dispositivos de E/S 

Los dispositivos de E/S se pueden dividir a grandes rasgos en dos categorías: dispositivos por bloques y 
dispositivos por caracteres. Un dispositivo por bloques almacena información en bloques de tamaño fijo, 
cada uno con su propia dirección. Los tamaños de bloque comunes van desde 512 bytes hasta 32 768 
bytes. La propiedad esencial de un dispositivo por bloques es que es posible leer o escribir cada bloque 
con independencia de los demás. Los discos son los dispositivos por bloques más comunes. 

Si lo analizamos con cuidado, la frontera entre los dispositivos que son direccionables por bloques y 
los que no lo son no se halla bien definida. Todo el mundo coincide en que un disco es un dispositivo 
direccionable por bloques, pues sea donde sea que esté el brazo actualmente, siempre es posible buscar 
otro cilindro y luego esperar que el bloque requerido gire, hasta pasar bajo la cabeza. Consideremos ahora 
una unidad de cinta DAT de 8 mm empleada para realizar respaldos de disco. Estas cintas generalmente 
contienen bloques de tamaño fijo. Si la unidad de cinta lee el bloque N, ésta siempre podrá rebobinar la 
cinta y avanzarla hasta llegar al bloque N. Esta operación es análoga a una búsqueda de disco, excepto que 
tarda mucho más. Además, podría o no ser posible reescribir un bloque a la mitad de una cinta. Incluso si 
fuera posible usar las cintas como dispositivos por bloques con acceso directo, ésta no es la forma como se 
usan normalmente. 

El otro tipo de dispositivo de E/S es el dispositivo por caracteres. Un dispositivo de este tipo 
suministra o acepta una corriente de caracteres, sin contemplar ninguna estructura de bloques; no es 
direccionable y no tiene una operación de búsqueda. Las impresoras, interfaces de red, ratones (para 
apuntar), ratas (para experimentos de laboratorio de psicología) y casi todos los demás dispositivos que no 
se parecen a los discos pueden considerarse como dispositivos por caracteres. 

Este esquema de clasificación no es perfecto; algunos dispositivos simplemente no se ajustan 
a él. Los relojes, por ejemplo, no son direccionables por bloques, ni tampoco generan ni aceptan 
flujos de caracteres; lo único que hacen es generar interrupciones a intervalos bien definidos. 
Las pantallas mapeadas en la memoria tampoco se ajustan muy bien al modelo. No obstante, el modelo 
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de dispositivos por bloques y por caracteres es lo bastante general como para servir de base para hacer que 
una parte del software del sistema operativo que se ocupa de E/S sea independiente del dispositivo. El 
sistema de archivos, por ejemplo, sólo maneja dispositivos por bloques abstractos y deja la parte 
dependiente del dispositivo a un software de más bajo nivel llamado controladores de dispositivos. 


3.1.2 Controladores de dispositivos 

Las unidades de E/S por lo regular consisten en un componente mecánico y otro electrónico. En muchos 
casos es posible separar las dos partes con objeto de tener un diseño más modular y general. El 
componente electrónico se llama controlador de dispositivo o adaptador. En las computadoras personales, 
este componente a menudo adopta la forma de una tarjeta de circuitos impresos que se puede insertar en 
una ranura de la tarjeta matriz de la computadora. El componente mecánico es el dispositivo mismo. 

La tarjeta controladora casi siempre tiene un conector en el que puede insertarse un cable que 
conduce al dispositivo. Muchos controladores pueden manejar dos, cuatro o incluso ocho dispositivos 
idénticos. Si la interfaz entre el controlador y el dispositivo es de un tipo estándar, ya sea una norma 
oficial como ANSI, IEEE o ISO, o una norma defacto, las compañías pueden fabricar controladores y 
dispositivos que se ajustan a esa interfaz. Por ejemplo, muchas compañías producen unidades de disco que 
se ajustan a las interfaces de controlador de disco IDE (Integrated Drive Electronics) o SCSI (Small 
Computer System Interface). 

Mencionamos esta distinción entre el controlador y el dispositivo porque el sistema operativo casi 
siempre trata con el controlador, no con el dispositivo. La mayor parte de las computadoras pequeñas usan 
el modelo de bus único de la Fig. 3-1 para la comunicación entre la CPU y los controladores. Las 
macrocomputadoras (mainframes) con frecuencia usan un modelo diferente, con múltiples buses y 
computadoras de E/S especializadas llamadas canales de 110 que asumen parte de la carga de la CPU 
principal. 



Figura 3-1. Modelo para conectar la CPU. la memoria, los controladores y los dispositivos 
de E/S. 


La interfaz entre el controlador y el dispositivo suele ser de nivel muy bajo. Un disco, por 
ejemplo, podría formatearse con 16 sectores de 512 bytes en cada pista. Sin embargo, lo 
que realmente sale de la unidad es un flujo de bits en serie que comienza con un preámbulo 
seguido de los 4096 bits del sector y por último una suma de verificación, llamada también código 
para corrección de errores (ECC: error-correcting code). El preámbulo se escribe cuando se da formato 
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al disco y contiene el número de cilindro y de sector, el tamaño de sector y datos similares, así como 
información de sincronización. 

La función del controlador consiste en convertir un flujo de bits a un bloque de bytes y realizar las 
acciones de corrección de errores necesarias. Generalmente, primero se arma el bloque de bytes, bit por 
bit, en un buffer dentro del controlador. Una vez que se ha cotejado su suma de verificación y se le declara 
libre de errores, el bloque puede copiarse en la memoria principal. 

El controlador de una terminal de tubo de rayos catódicos (CRT) también funciona como dispositivo 
de bits en serie en un nivel igualmente bajo: lee de la memoria bytes que contienen los caracteres por 
exhibir y genera las señales que modulan el haz del CRT para hacer que escriba en la pantalla. Además, el 
controlador genera las señales para hacer que el haz del CRT realice un barrido horizontal una vez que ha 
recorrido una línea, así como las señales que hacen que el haz realice un barrido vertical después de haber 
recorrido toda la pantalla. Si no fuera por el controlador del CRT, el programador del sistema operativo 
tendría que programar explícitamente la exploración analógica del tubo. Usando un controlador, el sistema 
operativo inicializa el controlador con unos cuantos parámetros, como el número de caracteres por línea y 
el número de líneas por pantalla, y deja que el controlador se encargue de guiar realmente el haz. 

Cada controlador tiene unos cuantos registros que sirven para comunicarse con la CPU. En algunas 
computadoras estos registros forman parte del espacio de direcciones de la memoria normal. Este esquema 
se denomina E/S mapeada en memoria. Por ejemplo, el 680x0 usa este método. Otras computadoras 
utilizan un espacio de direcciones especial para E/S, y a cada controlador se le asigna una porción. La 
asignación de direcciones de E/S a los dispositivos se realiza mediante lógica de descodificación del bus 
asociado al controlador. Algunos fabricantes de las llamadas IBM PC compatibles utilizan direcciones de 
E/S distintas de las que IBM usa. Además de los puertos de E/S, muchos controladores usan 
interrupciones para indicarle a la CPU cuándo están listos para que sus registros sean leídos o escritos. 
Una interrupción es, en primera instancia, un suceso eléctrico. Una línea de petición de interrupción (IRQ) 
de hardware es una entrada física del chip controlador de interrupciones. El número de tales entradas es 
limitado; las PC de tipo Pentium sólo tienen 15 entradas disponibles para dispositivos de E/S. Algunos 
controladores están alambrados físicamente en la tarjeta matriz del sistema, como, por ejemplo, el 
controlador del teclado en una IBM PC. En el caso de un controlador que se enchufa en el plano posterior, 
a veces pueden usarse interruptores o puentes de alambre en el controlador de dispositivo para seleccionar 
la IRQ que usará el dispositivo, a fin de evitar conflictos (aunque en algunas tarjetas, como Plug ‘n Play, 
las IRQ pueden establecerse en software). El chip controlador de interrupciones establece una 
correspondencia entre cada entrada IRQ y un vector de interrupción, que loca- liza la rutina de servicio de 
interrupción conespon A guisa de ejemplo, en la Fig. 3-2 se muestran las direcciones de E/S, 
interrupciones de hlsrdware y los vectores de interrupción asignados a algunos de los controladores de una 
IBM PC. MINIX usa las mismas interrupciones de hardware, pero los vectores de interrupción de MINIX 
son diferentes de los que se muestran aquí para MS-DOS. 

El sistema operativo realiza la E/S escribiendo comandos en los registros del controlador. 
Por ejemplo, el controlador de la unidad de disquete de una IBM PC acepta 15 comandos distintos, 
como READ (leer), WRITE (escribir), SEEK (buscar), FORMAT (formatear) y RECALIBRATE 
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figura 3-2. Algunos ejemplos de controladores, sus direcciones de E/S, sus líneas de interrup¬ 
ción de hardware y sus vectores de interrupción en una PC típica que ejecuta MS-DOS 


(recalibrar). Muchos de los comandos tienen parámetros, que también se cargan en los registros del 
controlador. Una vez que un controlador ha aceptado un comando, la CPU puede dejarlo libre y ponerse a 
hacer otra cosa. Una vez que se ha llevado a cabo el comando, el controlador causa una interrupción para 
que el sistema operativo pueda recuperar el control de la CPU y probar los resultados de la operación. La 
CPU obtiene los resultados y el estado del dispositivo leyendo uno o más bytes de in formación de los 
registros del controlador. 


3,1,3 Acceso directo a memoria (DMA) 

Muchos controladores, sobre todo los de dispositivos por bloques, manejan el acceso directo a memoria o 
DMA. Para explicar el funcionamiento del DMA, veamos primero cómo ocurren las lecturas de disco 
cuando no se usa DMA. Primero el controlador lee el bloque (uno o más sectores) de la unidad en serie, 
bit por bit, hasta que todo el bloque está en el buffer interno del controlador. A continuación, el 
controlador calcula la suma de verificación para comprobar que no ocurrieron errores de lectura, y luego 
causa una interrupción. Cuando el sistema operativo comienza a ejecutarse, puede leer el bloque del disco 
del buffer del controlador byte por byte o palabra por palabra, ejecutando un ciclo, leyéndose en cada 
iteración un byte o una palabra de un registro del controlador y almacenándose en la memoria. 

Naturalmente, un ciclo de la CPU programado para leer los bytes del controlador uno por uno 
desperdicia tiempo de CPU. Se inventó el DMA para liberar a la CPU de este trabajo de bajo nivel. 
Cuando se usa DMA, la CPU proporciona al controlador dos elementos de información, además de la 
dirección en disco del bloque: la dirección de memoria donde debe colocarse el bloque y el número de 
bytes que deben transferirse, como se muestra en la Fig. 3-3. 

Una vez que el controlador ha leído todo el bloque del dispositivo, lo ha colocado en su buffer 
y ha calculado la suma de verificación, copia el primer byte o palabra en la memoria principal 
en la dirección especificada por la dirección de memoria de DMA. Luego, el controlador 
incrementa la dirección de DMA y decrementa la cuenta de DMA en el número de bytes que se acaban de 
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Figura 3-3. Una transferencia DMA es realizada totalmente por el controlador 


transferir. Este proceso se repite hasta que la cuenta de DMA es cero, y en ese momento el controlador 
causa una interrupción. Cuando el sistema operativo inicia, no tiene que copiar el bloque en la memoria; 
ya está ahí. 

Tal vez usted se esté preguntando por qué el controlador no almacena los bytes en la memoria 
principal tan pronto como los recibe del disco. En otras palabras, ¿por qué necesita un buffet intemo? La 
razón es que una vez que se ha iniciado una transferencia de disco, los bits siguen llegando del disco a 
velocidad constante, sea que el controlador esté listo o no para recibirlos. Si el controlador tratara de 
escribir los datos directamente en la memoria, tendría que hacerlo a través del bus del sistema para cada 
palabra transferida. Si el bus estuviera ocupado porque otro dispositivo lo está usando, el controlador 
tendría que esperar. Si la siguiente palabra del disco llegara antes de que la anterior se almacenara en la 
memoria, el controlador tendría que ponerla en algún lado. Si el bus estuviera muy ocupado, el 
controlador podría tener que almacenar una buena cantidad de palabras y también realizar un gran número 
de tareas administrativas. Si el bloque se guarda en un buffer intemo, no se necesitará el bus en tanto no se 
inicie el DMA, y el diseño del controlador será mucho más sencillo porque la transferencia DMA a 
memoria no depende críticamente del tiempo. (De hecho, algunos controladores viejos sí transferían 
directamente a memoria con un mínimo de almacenamiento intermedio intemo, pero cuando el bus estaba 
muy ocupado a veces era necesario terminar una transferencia con un error de desbordamiento.) 

El proceso con almacenamiento intermedio de dos pasos que acabamos de describir tiene 
implicaciones importantes para el rendimiento de E/S. Mientras los datos están siendo transferidos del 
controlador a la memoria, sea por la CPU o por el controlador, el siguiente sector estará pasando bajo la 
cabeza del disco y los bits estarán llega al controlador. Los controladores sencillos simplemente no pueden 
efectuar entrada y salida al mismo tiempo, de modo que mi entras se está realizando una transferencia a la 
memoria el sector/que pasa bajo la cabeza del disco se pierde. 

En consecuencia, el controlador sólo puede—leer bloques de manera intercalada, es decir, uno sí y 
uno no, de modo que la lectura de toda una pista requiere dos rotaciones completas, una para los bloques 
pares y otra para los impares. Si el tiempo que toma transferir un bloque del controlador a la memoria por 
el bus es más largo que el que toma leer un bloque del disco, puede ser necesario leer un bloque y luego 
saltarse dos (o más) bloques. 

Saltarse bloques para dar al controlador tiempo de transferir los datos a la memoria se 
denomina intercalación. Cuando se da formato al disco, los bloques se numeran teniendo en cuenta el 
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factor de intercalación. En la Fig. 3-4(a) vemos un disco con ocho bloques por pista y cero intercalación. 
En la Fig. 3-4(b) vemos el mismo disco con intercalación sencilla. En la Fig. 3-4(c) ilustra la intercalación 
doble. 



(«I <t>) (c) 

Figura 3-4. (a) Sin intercalación (b) Intercalación rencilla, (c) Intercalación doble. 


El objetivo de numerar los bloques de este modo es permitir que el sistema operativo lea Noques 
numerados consecutivamente y aun así logre la máxima velocidad de que el hardware es capaz. Si los 
bloques se numeraran como en la Fig. 3-4(a) pero el controlador sólo pudiera leer bloques alternados, un 
sistema operativo que se encargara de distribuir un archivo de ocho bloques en bloques de disco 
consecutivos requeriría ocho rotaciones de disco para leer los bloques &10 al 7 en orden. (Desde luego, si 
el sistema operativo se diera cuenta del problema y repartiera los bloques recibidos de forma diferente en 
la memoria, podría resolver el problema en software, pero es mejor dejar que el controlador se preocupe 
por la intercalación.) 

No todas las computadoras usan DMA. El argumento en su contra es que en muchos casos la CPU 
principal es mucho más rápida que el controlador de DMA y puede realizar el trabajo en mucho menos 
tiempo (cuando el factor limitante no es la rapidez del dispositivo de E/S). Si la CPU (rápida) no tiene otra 
cosa que hacer, obligarla a esperar hasta que el controlador de DMA (lento) termine no tiene sentido. 
Además, si se omite el controlador de DMA y se deja que la CPU realice todo el trabajo, se ahorra algo de 
dinero. 


3.2 PRINCIPIOS DEL SOFTWARE DE E/S 

Dejemos ahora el hardware y examinemos la forma como está estructurado el software de E/S. Los 
objetivos generales del software de E/S son fáciles de plantear. La idea básica es organizar el software 
como una serie de capas, y que las inferiores oculten las peculiaridades del hardware para que las capas 
superiores no las vean. Las capas superiores se ocuparán de presentar una interfaz bonita, aseada y regular 
a los usuarios. En las siguientes secciones estudiaremos estos objetivos y la forma de lograrlos. 


3.2.1 Objetivos del software de E/S 

Un concepto clave del diseño de software de E/S se conoce como independencia del dispositivo. 
Esto significa que debe ser posible escribir programas que puedan leer archivos de un disquete, 
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un disco duro o un CD-ROM sin tener que modificar los programas para cada tipo de dispositivo distinto. 
Debemos poder teclear un comando como 

sort <entrada >salida 

y hacer que funcione con entradas provenientes de un disco flexible, un disco duro o el teclado, y 
enviando las salidas al disco flexible, el disco duro o incluso la pantalla. Es responsabilidad del sistema 
operativo resolver los problemas causados por el hecho de que estos dispositivos en realidad son distintos 
y requieren controladores en software muy distintos para escribir los datos en el dispositivo de salida. 

Algo muy relacionado con la independencia del dispositivo es el objetivo de nombres uniformes. El 
nombre de un archivo o un dispositivo debe ser simplemente una cadena y un entero y no : 1 depender del 
dispositivo de forma alguna. En UNIX, todos los discos se pueden integrar en la jerarquía del sistema de 
archivos de formas arbitrarias, de modo que el usuario no necesita saber qué nombre corresponde a qué 
dispositivo. Por ejemplo, un disco flexible puede montarse sobre el directorio /usr/a st/respaldo! de modo 
que si copiamos un archivo en /usr/ast/respaldo/lunes lo estaremos copiando en el disquete. Así, todos los 
archivos y dispositivos se direccionan de la misma forma: con un nombre de trayectoria. 

Otro aspecto importante del software de E/S es el manejo de errores. En general, los errores deben 
manejarse tan cerca del hardware como sea posible. Si el controlador descubre un error de lectura, debe 
tratar de corregirlo él mismo, si puede. Si no puede, el controlador en software debería manejarlo, tal vez 
tratando simplemente de leer el bloque otra vez. Muchos errores son transitorios, como los errores de 
lectura causados por partículas de polvo en la cabeza de lectura, y desaparecen si la operación se repite. 
Sólo si las capas inferiores son incapaces de resolver el problema se deberá informar de él a las capas 
superiores. En muchos casos, la recuperación de errores puede efectuarse de manera transparente en un 
nivel bajo sin que los niveles superiores se enteren siquiera de que ocurrió un error. 

Otro aspecto clave es si las transferencias son síncronas (por bloqueo) o asincronas (controladas por 
interrupciones). En general, la E/S física es asincrona: la CPU inicia la transferencia y se dedica a otra 
cosa hasta que llega la interrupción. Los programas de usuario son mucho más fáciles de escribir si las 
operaciones de E/S provocan bloqueos: después de un comando READ el programa se suspende 
automáticamente hasta que hay datos disponibles en el buffer. Le corresponde al sistema operativo hacer 
que las operaciones que en realidad son controladas por interrupciones parezcan controladas por bloqueo a 
los programas de usuario. 

El último concepto que veremos aquí es el de dispositivos de uso exclusivo y no exclusivo. Algunos 
dispositivos de E/S, como los discos, pued utilizados por muchos usuarios al mismo tiempo. No hay 
problemas si varios usuarios tienen archivos abiertos en el mismo disco al mismo tiempo. Otros 
dispositivos, como las unidades de cinta, tienen que estar dedicados a un solo usuario hasta que éste haya 
terminado. Luego, otro usuario puede disponer de la unidad de cinta. Si dos o más usuarios escriben 
bloques entremezclados al azar en la misma cinta, se generará el caos. La introducción de dispositivos de 
uso exclusivo (no compartidos) da lugar a diversos problemas. Una vez más, el sistema operativo debe 
poder manejar dispositivos tanto compartidos como de uso exclusivo de manera tal que se eviten 
problemas. 



SEC 3.2 


PRINCIPIOS DEL SOFTWARE DE E/S 


161 


Estos objetivos se pueden lograr de una forma lógica y eficiente estructurando el software de E/S en 
cuatro capas: 

1. Manejadores de interrupciones (capa inferior) 

2. Controladores de dispositivos en software. 

3. Software del sistema operativo independiente del software. 

4. Software de usuario (capa superior). 


Estas cuatro capas son (no por coincidencia) las mismas que vimos en la Fig. 2-26. En las siguientes 
secciones las examinaremos una por una, comenzando por abajo. En este capítulo haremos hi en los 
controladores de dispositivos (capa 2), pero resumiremos el resto del software de ‘S para mostrar cómo se 
relacionan las diferentes piezas del sistema de E/S. 


3.2.2 Manejadores de interrupciones 

Las interrupciones son desagradables pero inevitables, y deben ocultarse en las profundidades del sistema 
operativo, con el fin de reducir al mínimo las partes del sistema que tienen conocimiento de ellas. La 
mejor forma de ocultarlas es hacer que cada proceso inicie un bloqueo de operación de WS hasta que la 
E/S se haya llevado a cabo y la interrupción ocurra. El proceso puede bloquearse ejecutando un DOWN 
con un semáforo, un WA con una variable de condición o un RECEIVE con un mensaje, por ejemplo. 

Cuando sucede la interrupción, el procedimiento de interrupciones hará lo que tenga que hacer para 
desbloquear el proceso que la originó. En algunos sistemas se ejecutará un uP con un semáforo; en otros, 
se ejecutará un SIGNAL con una variable de condición en un monitor. En otros más, se enviará un 
mensaje al proceso bloqueado. En todos los casos, el efecto neto de la interrupción será que un proceso 
que estaba bloqueado está ahora en condiciones de ejecutarse. 


3.2.3 Controladores de dispositivos 

Todo el código dependiente del dispositivo se coloca en los controladores de dispositivo. Cada controlador 
maneja un tipo de dispositivo o, cuando más, una clase de dispositivos similares. Por ejemplo, podría ser 
aconsejable tener un solo controlador de terminal, aun si el sistema maneja terminales de distintas marcas, 
todas con pequeñas diferencias. Por otro lado, una terminal mecánica tonta que produce salidas impresas y 
una ter mi nal inteligente con gráficos de mapa de bits y ratón son tan distintas que es preciso usar 
diferentes controlado en software. 

En una sección anterior del capítulo explicamos lo que hacen los controladores de dispositivos en 
hardware. Vimos que cada controlador tiene uno o más registros de dispositivo que sirven para aceptar 
comandos. Los controladores en software emiten estos comandos y verifican que se ejecuten 
correctamente. Así, el controlador de disco en software es la única parte del sistema operativo que sabe 
cuántos registros tiene ese controlador de disco en hardware y para qué sirven. Sólo él sabe algo de 
sectores, pistas, cilindros, cabezas, movi mi ento del brazo, factores de 
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intercalación, motores, tiempos de asentamiento de la cabeza y todos los demás aspectos mecánicos del 
funcionamiento correcto del disco. 

En términos generales, la tarea de un controlador de dispositivo en software es aceptar peticiones 
abstractas del software independiente del dispositivo que está arriba de él y ver que dichas peticiones sean 
atendidas. Una petición típica sería leer el bloque n. Si el controlador está ocioso en el momento en que 
llega una petición, comenzará a atenderla de inmediato, pero si ya está ocupado con otra petición, 
normalmente colocará la nueva petición en una cola de peticiones pendientes que se atenderán tan pronto 
como sea posible. 

El primer paso para atender realmente una petición de E/S, digamos para un disco, es traducirla de 
términos abstractos a concretos. En el caso de un controlador de disco, esto implica calcular en qué parte 
del disco está realmente el bloque solicitado, verificar si el motor de la unidad está funcionando, 
determinar si el brazo está colocado en el cil in dro apropiado, etc. En pocas palabras, el controlador en 
software debe decidir qué operaciones del controlador son necesarias en el hardware y en qué orden. 


Una vez que el controlador en software ha decidido qué comandos debe e mi tir al controlador en 
hardware, comenzará a emitirlos escribiendo en los registros de dispositivo de este último. Algunos 
controladores en hardware sólo pueden manejar un comando a la vez; otros están dispuestos a aceptar una 
lista enlazada de comandos, que luego ejecutan por su cuenta sin más ayuda del sistema operativo. 

Una vez que se ha emitido el comando o comandos, se presentará una de dos situaciones. En 
muchos casos el controlador en software debe esperar hasta que el controlador en hardware realice cierto 
trabajo, así que se bloquea hasta que llega la interrupción para desbloquearlo. En otros casos, sin embargo, 
la operación se lleva a cabo sin dilación, y el controlador no necesita bloquearse. Como ejemplo de una 
situación de este tipo, el recorrido en la pantalla en algunas terminales sólo requiere la escritura de unos 
cuantos bytes en los registros del controlador en hardware. No se requiere movimiento mecánico, así que 
toda la operación puede llevarse a cabo en unos cuantos microsegundos. 

En el primer caso, el controlador bloqueado será despertado por la interrupción; en el segundo, 
nunca se dormirá. De cualquier manera, una vez que se ha efectuado la operación el controlador debe 
determinar si no ocurrieron errores. Si todo está bien, el controlador puede tener datos que pasar al 
software independiente del dispositivo (p. ej., el bloque que acaba de leerse). Por último, el controlador 
devuelve información de estado para informar de errores a su invocador. Si hay otras peticiones en cola, 
puede seleccionarse e inicia una de ellas. Si no hay nada en la cola, el controlador se bloquea esperando la 
siguiente petición. 


3.2.4 Software de E/S independiente del dispositivo 

Aunque una parte del software de E/S es específica para cada dispositivo, una fracción considerable es 
independiente de él. La frontera exacta entre los controladores de dispositivos y el software independiente 
del dispositivo depende del sistema, porque algunas funciones que podrían realizarse 
de forma independiente del dispositivo podrían efectuarse realmente en los controladores 
en software, por razones de eficiencia o de otro tipo. Las funciones que se muestran en la Fig. 3-5 por 
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lo regular se realizan en el software independiente del dispositivo. En MINIX, casi todo el software 
independiente del dispositivo forma parte del sistema de archivos, en la capa 3 (Fig. 2-26). Aunque 
estudiaremos el sistema de archivos en el capítulo 5, daremos aquí un vistazo al software independiente 
del dispositivo, a fin de tener un panorama más completo de la E/S y poder explicar mejor donde encajan 
los controladores. 


Interfaz uniforme para los controladores de dispositivos 

Nombres de dispositivos 

Protección de dispositivos 

Tamaño de bloque independiente del dispositivo 

Almacenamiento intermedio 

Asignación do almacenamiento en dispositivos por bloques 
Asignación y liberaciónde dispositivos dedicados 
Informe de errores 

Figura 3-5. Funciones del software de E/S independiente del dispositivo. 


La función básica del software independiente del dispositivo es realizar las funciones de E/S 
comunes a todos los dispositivos y presentar una interfaz uniforme al software de nivel de usuario. 

Un aspecto importante de cualquier sistema operativo es cómo se nombran los objetos tales como 
archivos y dispositivos de E/S. El software independiente del dispositivo se encarga de establecer la 
correspondencia entre los nombres simbólicos de dispositivo y el controlador apropia do. En UNIX un 
nombre de dispositivo, como /dev/ttyOO, especifica de manera única el nodo-i de un archivo especial, y 
este nodo-i contiene el número principal del dispositivo, que sirve para localizar el controlador apropiado. 
El nodo-i también contiene el número secundario del dispositivo, que se pasa como parámetro al 
controlador a fin de especificar la unidad que se leerá o escribirá. 

Algo muy relacionado con los nombres es la protección. ¿Cómo impide el sistema que los usuarios 
puedan acceder a dispositivos que no están facultados para ello? En la mayor parte de los Sistemas de 
computadora personal no hay protección. Cualquier proceso puede hacer lo que quiera. En las 
macroconiputadoras, el acceso a los dispositivos de E/S por parte de los procesos de usuario está 
estrictamente prohibido. En UNIX se utiliza un esquema más flexible. Los archivos especiales que 
corresponden a los dispositivos de FIS se protegen con los bits rwx usuales. Así, el administrador del 
sistema puede establecer los permisos adecuados para cada dispositivo. 

Diferentes discos pueden tener tamaños de sectores distintos. Corr, al software independiente del 
dispositivo ocultar este hecho y proveer un tamaño dehíoque uniforme a las capas superiores, por ejemplo, 
tratando varios sectores como un solo bloque lógico. De esta forma, las capas superiores sólo manejan 
dispositivos abstractos que siempre usan el mismo tamaño de bloque lógico, sea cual sea el tamaño de los 
sectores físicos. De forma similar, algunos dispositivos por caracteres suministran sus datos byte por byte 
(como los módems) mientras que otros los suministran en unidades más grandes (como las interfaces de 
red). Estas diferencias también deben ocultarse. 

El almacenamiento intermedio también es una cuestión importante, tanto para los dispositivos 
por bloques como para los de caracteres. En el primer caso, el hardware generalmente insiste en 
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leer y escribir bloques completos a la vez, pero los procesos de usuario están en libertad de leer y escribir 
en unidades arbitrarias. Si un proceso de usuario escribe medio bloque, el sistema operativo normalmente 
guardará los datos internamente hasta que se escriba el resto de los datos, y en ese momento se podrá 
grabar el bloque en el disco. En el caso de los dispositivos por caracteres, los usuarios podrían escribir los 
datos al sistema con mayor velocidad que aquella a la que pueden salir, lo que requeriría almacenamiento 
intermedio (buffers). De igual manera, la entrada del teclado que llega antes de que sea necesaria también 
requiere buffers. 

Cuando se crea un archivo y se llena con datos, es preciso asignar nuevos bloques de disco al 
archivo. Para poder realizar esta asignación, el sistema operativo necesita una lista o un mapa de bits de 
los bloques libres del disco, pero el algoritmo para localizar un bloque libre es independiente del 
dispositivo y se puede efectuar en un nivel más alto que el del manejador. 

Algunos dispositivos, como las grabadoras de CD-ROM, sólo pueden ser utilizados por un solo 
proceso en determinado momento. Corresponde al sistema operativo examinar las peticiones de uso del 
dispositivo y aceptarlas o rechazarlas, dependiendo de si el dispositivo solicitado está disponible o no. Una 
forma sencilla de manejar estas peticiones es exigir a los procesos que ejecuten instrucciones OPEN en los 
archivos especiales de los dispositivos de forma directa. Si el dispositivo no está disponible, el OPEN 
fallará. Al cerrar tal dispositivo de uso exclusivo, éste se liberaría. 

El manejo de errores generalmente lo realizan los controladores. La mayor parte de los errores son 
altamente dependientes del dispositivo, de modo que sólo el controlador sabe qué debe hacerse (p. ej., 
reintentar, ignorar, situación de pánico). Un error típico es el causado por un bloque de disco que se dañó 
y ya no puede leerse. Después de que el controlador ha tratado de leer el bloque cierto número de veces, se 
da por vencido e informa de ello al software independiente del dispositivo. La forma como el error se trata 
de aquí en adelante es independiente del dispositivo. Si el error ocurrió mientras se estaba leyendo un 
archivo de usuario, puede ser suficiente informar del error al invocador. Sin embargo, si el error ocurrió 
durante la lectura de una estructura de datos crítica del sistema, como el bloque que contiene el mapa de 
bits que indica cuáles bloques están libres, puede ser que el sistema operativo no tenga más opción que 
imprimir un mensaje de error y terminar. 


3.2.5 Software de E/S de espacio de usuario 

Aunque la mayor parte del software de E/S está dentro del Ssistema operativo, una pequeña parte de él 
consiste en bibliotecas enlazadas a los programas s 1/usuario, e incluso en programas completos que se 
ejecutan fuera del kemel. Las llamad entre ellas las E/S, normalmente son efectuadas por procedimientos 
de biblioteca. Cuando un programa en C contiene la llamada 

count = write(fd, buffer, nbytes); 

el procedimiento de biblioteca write se enlazará al programa y estará contenido en el programa binario 
presente en la memoria en el momento de la ejecución. La colección de todos estos procedimientos de 
biblioteca evidentemente forma parte del sistema de E/S. 

Si bien estos procedimientos no hacen mucho más que colocar sus parámetros en el lugar 
apropiado para la llamada al sistema, hay otros procedimientos de E/S que sí realizan trabajo de 
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verdad. En particular, el formateo de entradas y salidas se realiza mediante procedimientos de biblioteca. 
Un ejemplo de C es printf, que toma una cadena de formato y posiblemente algunas variables como 
entrada, construye una cadena ASCII y luego invoca WRITE para enviar la cadena a la salida. Un ejemplo 
de un procedimiento similar para la entrada lo constituye scanf que lee entradas y las almacena en 
variables descritas en una cadena de formato que tiene la misma sintaxis que prinlf. La biblioteca de E/S 
estándar contiene varios procedimientos que implican E/S, y todos se ejecutan como parte de programas 
de usuario. 

No todo el software de E/S de nivel de usuario consiste en procedimientos de biblioteca. Otra 
categoría importante es el sistema de spool. El uso de spool es una forma de manejar los dispositivos de 
E/S de uso exclusivo en un sistema multiprogramado. Consideremos un dispositivo spooi típico: una 
impresora. Aunque desde el punto de vista técnico sería fácil dejar que cualquier proceso de usuario 
abriera el archivo especial por caracteres de la impresora, podría suceder que un proceso lo abriera y luego 
pasara horas sin hacer nada. Ningún otro proceso podría imprimir nada. 

En vez de ello, lo que se hace es crear un proceso especial, llamado genéricamente demonio, y un 
directorio especial, llamado directorio de spool. Si un proceso quiere imprimir un archivo, primero genera 
el archivo completo que va a imprimir y lo coloca en el directorio de spool. Corresponde al demonio, que 
es el único proceso que tiene permiso de usar el archivo especial de la impresora, escribir los archivos en 
el directorio. Al proteger el archivo especial contra el uso directo por parte de los usuarios, se eli mi na el 
problema de que alguien lo mantenga abierto durante un tiempo innecesariamente largo. 

El spool no se usa sólo para impresoras; también se usa en otras situaciones. Por ejemplo, es común 
usar un demonio de red para transferir archivos por una red. Si un usuario desea enviar un archivo a algún 
lado, lo coloca en un directorio de spool de red. Más adelante, el demonio de red lo toma de ahí y lo 
transmite. Una aplicación especial de la transmisión de archivos por spool es el sistema de correo 
electrónico de Internet. Esta red consiste en millones de máquinas en todo el mundo que se comunican 
empleando muchas redes de computadoras. Si usted desea enviar correo a alguien, invoca un programa 
como send, que acepta la carta que se desea enviar y la deposita en un directorio de spool para ser 
transmitida posteriormente. Todo el sistema de correo se ejecuta fuera del sistema operativo. 

En la Fig. 3-6 se resume el sistema de E/S, con todas las capas y las funciones principales de cada 
capa. Comenzando por abajo, las capas son el hardware, los manejadores de interrupciones, los 
controladores de dispositivos, el software independiente del dispositivo y por último los procesos de 
usuario. 

Las flechas de la Fig. 3-6 indican el flujo de control. Por ejemplo, cuan un proceso de usuario trata de 
leer un bloque de un archivo, se invoca el sistema operativo p ejecute la llamada. El software 
independiente del dispositivo busca, por ejemplo, en el caché de bloques. Si el bloque que se necesita no 
está ahí, ese software invoca el controlador de dispositivo para que emita la petición al hardware. A 
continuación el proceso se bloquea hasta que se lleva a cabo la operación de disco. 

Cuando el disco termina, el hardware genera una interrupción. Se ejecuta el manejador de 
interrupciones para descubrir qué ha sucedido, es decir, cuál dispositivo debe atenderse en este momento. 
El manejador extrae entonces el estado del dispositivo y despierta al proceso dormido para que finalice la 
petición de E/S y permita al proceso de usuario continuar. 
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de E/S Funciones de E/S 

Realizar llamada de E/S; formatear E/S; spool 

Nombres, protección, bloques, 
almacenamiento intermedio, asignación 

Preparar registros de dispositivo, verificar estado 

Despertar al controlador al finalizarse la E/S 

Realizar operación de E/S 


Figura 3-6. Capas del sistema de E/S y funciones principales de cada capa. 


3.3 BLOQUEO MUTUO 

Los sistemas de cómputo tienen muchos recursos que sólo pueden ser utilizados por un proceso a la vez. 
Ejemplos comunes de ellos son los graficadores de cama plana, los lectores de CD ROM, las grabadoras 
de CD-ROM, los sistemas de respaldo en cinta DAT de 8 rnm, los formadores de imágenes y las ranuras 
de la tabla de procesos del sistema. Tener dos procesos escribiendo simultáneamente en una impresora 
produce basura. Tener dos procesos usando la misma ranura de la tabla de procesos probablemente 
causaría una caída del sistema. Por ello, todos los sistemas operativos tienen la capacidad de conceder 
(temporalmente) a un proceso acceso exclusivo a ciertos recursos. 

En muchas aplicaciones, un proceso necesita acceso exclusivo no a un recurso, sino a varios. 
Consideremos, por ejemplo, una compañía de marketing que se especializa en preparar mapas 
demográficos detallados en un graficador de cama plana de 1 m de ancho. La información demográfica 
proviene de los CD-ROM que contienen datos censuales y de otro tipo. Supongamos que el proceso A 
solicita la unidad de CD-ROM y la obtiene. Un momento después, el proceso B solicita el graficador y 
también lo obtiene. Ahora el proceso A solicita el graficador y se bloquea esperándolo. Por último, el 
proceso B solicita la unidad de CD-ROM y también se bloquea. En este punto ambos procesos quedan 
bloqueados y permanecen así eternamente. Esta situación se denomina bloqueo mutuo. No conviene tener 
bloqueo un sistema. 

Los bloqueos mutuos pueden ocurrir en muchas situaciones además de la petición de dispositivos de 
E/S de uso exclusivo. Por ejemplo, en un sistema de base de datos, un programa podría tener que poner un 
candado a varios registros que está usando, a fin de evitar condiciones de competencia. Si el proceso A 
asegura el registro R1 y el proceso B asegura el registro R2, y luego cada proceso trata de asegurar el 
registro del otro, también tendremos un bloqueo mutuo. Por tanto, los bloqueos mutuos pueden ocurrir con 
recursos de hardware o de software. 

En esta sección exa mi naremos los bloqueos mutuos con mayor detenimiento para ver cómo 
surgen y cómo pueden prevenirse o evitarse. Como ejemplos, hablaremos de adquirir dispositivos 
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físicos como unidades de cinta, unidades de CD-ROM y graficadores, porque son fáciles de visualizar, 
pero los principios y algoritmos se aplican igualmente bien a otros tipos de bloqueos mutuos. 


3.3.1 Recursos 

Los bloqueos mutuos pueden ocurrir cuando se otorga a los procesos acceso exclusivo a dispositivos, 
archivos, etc. A fin de hacer la explicación de los bloqueos mutuos lo más general posible, nos referiremos 
a los objetos otorgados como recursos. Un recurso puede ser un dispositivo de hardware (p. ej., una unidad 
de cinta) o un elemento de información (p. ej., un registro con candado en una base de datos). Una 
computadora normalmente tiene muchos recursos distintos que se pueden adquirir. Para algunos recursos 
pueden estar disponibles varios ejemplares idénticos, como tres unidades de cinta. Cuando están 
disponibles varias copias de un recurso, cualquiera de ellas puede usarse para satisfacer cualquier petición 
del usuario por ese recurso. En pocas palabras, un recurso es cualquier cosa que sólo puede ser usada por 
un proceso en un instante dado. 

Los recursos son de dos tipos: expropiables y no expropiables. Un recurso expropiable es uno que se 
puede arrebatar al proceso que lo tiene sin que haya efectos adversos. La memoria es un ejemplo de 
recurso expropiable. Consideremos, por ejemplo, un sistema con 512K de memoria de usuario, una 
impresora y dos procesos de 512K que quieren imprimir algo. El proceso A solicita y obtiene la 
impresora, y comienza a calcular los valores que va a imprimir, pero antes de que haya terminado el 
cálculo excede su cuanto de tiempo y es intercambiado a disco. 

Ahora se ejecuta el proceso B e intenta, sin éxito, adquirir la impresora. Aquí tenemos una situación 
de bloqueo mutuo en potencia, porque A tiene la impresora y B tiene la memoria, y ninguno puede 
proceder sin el recurso que el otro tiene. Por fortuna, es posible quitarle la memo ría a B (expropiarla) 
intercambiando B a disco e intercambiando A a la memoria. Ahora A puede ejecutarse, imprimir, y por 
último liberar la impresora. No hay bloqueo mutuo. 

En contraste, un recurso no expropiable no puede quitársele a su poseedor actual sin hacer que el 
cómputo falle. Si un proceso ya comenzó a imprimir salidas y se le quita la impresora para dársela a otro 
proceso, se obtendrá basura como salida. Las impresoras no son expropiables. 

En general, en los bloqueos mutuos intervienen recursos no expropiables. Los bloqueos mutuos en 
potencia en los que intervienen recursos expropiables casi siempre pueden resolverse reasignando los 
recursos de un proceso a otro. Por tanto, nuestro tratamiento se centrará en los recursos no apropiables. 

La secuencia de sucesos que se requiere para usar un recurso es: 

1. Solicitar el recurso. 

2. Usar el recurso. 

3. Liberar el recurso. 

Si el recurso no está disponible cuando se solicita, el proceso que realiza la solicitud tiene que 
esperar. En algunos sistemas operativos, el proceso se bloquea automáticamente cuando una petición 
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de recurso falla, y se le despierta cuando el recurso está disponible. En otros sistemas, la petición falla con 
un código de error, y toca al proceso invocador esperar un poco e intentarlo de nuevo. 


3.3.2 Principios del bloqueo mutuo 

El bloqueo mutuo puede definirse formalmente como sigue: 


Un conjunto de procesos está en bloqueo mutuo si cada proceso del conjunto está esperando un 
evento que sólo otro proceso del conjunto puede causar. 


Puesto que todos los procesos están esperando, ninguno de ellos puede causar ninguno de los eventos que 
podrían despertar a cualquiera de los demás miembros del conjunto, y todos los proce sos continúan 
esperando indefinidamente. 

En la mayor parte de los casos, el evento que cada proceso está esperando es la liberación de algún 
recurso que actualmente está en poder de otro miembro del conjunto. Dicho de otro modo, cada miembro 
del conjunto de procesos mutuamente bloqueado está esperando un recurso que está en poder de otro 
proceso en bloqueo. Ninguno de los procesos puede ejecutarse, ninguno puede liberar ningún recurso, y 
ninguno puede ser despertado. Ni el número de los procesos ni el número y tipo de los recursos poseídos y 
solicitados son importantes. 


Condiciones para el bloqueo mutuo 

Coffinan et al. (1971) demostraron que deben cumplirse cuatro condiciones para que haya un bloqueo 
mutuo: 

1. Condición de exclusión mutua. Cada recurso está asignado únicamente a un solo proceso o está 
disponible. 

2. Condición de retener y esperar. Los procesos que actualmente tienen recursos que les fueron 
otorgados previamente pueden solicitar nuevos recursos. 

3. Condición de no expropiación. No es posible quitarle por la fúerza a un proceso los recursos que 
le fúeron otorgados previamente. El proceso que los tiene debe liberarlos explícitamente. 

4. Condición de espera circular. Debe haber una cadena circular de dos o más procesos, cada uno de 
los cuales está esperando un recurso retenido por el siguiente miembro de la cadena. 

Deben estar presentes estas cuatro condiciones para que ocurra un bloqueo mutuo. Si una o más de estas 
condiciones está ausente, no puede haber bloqueo mutuo. 
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Holt (1972) mostró cómo pueden modelarse estas cuatro condiciones usando grafos dirigidos. Los grafos 
tienen dos clases de nodos: procesos, que se indican con círculos, y recursos, que se indican pon 
cuadrados. Un arco que va de un nodo de recurso (cuadrado) a uno de proceso (círculo) indica que el 
recurso fue solicitado previamente por el proceso, le fue concedido, y actualmente está en su poder. En la 
Fig. 3-7(a) el recurso R está asignado actualmente al proceso A. 


© 0 


0 © 

(«) (b) 

Figura 3*7. Grafos de asignación de recursos, (a) Retención de un recurso, (b) Petición de un 
recurso, (c) Bloqueo mutuo. 



Un arco de un proceso a un recurso indica que el proceso está bloqueado esperando ese recurso. En 
la Fig. 3-7(b) el proceso B está esperando el recurso S. En la Fig. 3-7(c) vemos un bloqueo mutuo: el 
proceso C está esperando el recurso T, que actualmente está en poder del proceso E), El proceso D no va a 
liberar el recurso T porque está esperando el recurso U, que está en poder de C. Ambos procesos esperarán 
eternamente. Un ciclo en el grafo implica que hay un bloqueo mutuo en el que intervienen los procesos y 
recursos del ciclo. En este ejemplo, el ciclo es C-T-D-U-C. 

Examinemos ahora un ejemplo de cómo pueden usarse los grafos de recursos. Imagine que tenemos 
tres procesos, A, 8 y C, y tres recursos, R, S y T. Las peticiones y liberaciones de los tres procesos se 
muestran en la Fig. 3-8(a)-(c). El sistema operativo está en libertad de ejecutar cualquier proceso no 
bloqueado en cualquier instante, de modo que podría decidir ejecutar A hasta que A terminara todo su 
trabajo, luego 8 hasta su finalización y por último C. 

Este ordenamiento no da lugar a ningún bloqueo mutuo (porque no hay competencia por los 
recursos) pero tampoco tiene paralelismo. Además de solicitar y liberar recursos, los procesos calculan y 
realizan LIS. Cuando los procesos se ejecutan secuencialmente, no existe la posibilidad de que mi entras 
un proceso está esperando LIS el otro pueda usar la CPU. Por tanto, ejecutar los procesos en forma 
estrictamente secuencial podría no ser óptimo. Por otro lado, si ninguno de los procesos realiza LIS, el 
algoritmo del primer trabajo más corto es mejor que el round robín, así que en algunas circunstancias lo 
mejor podría ser ejecutar todos los procesos secuencialmente. 

Supongamos ahora que los procesos realizan tanto LIS como cálculos, de modo que el round 
robín es un algoritmo de planificación razonable. Las peticiones de recursos podrían presentarse 
en el orden que se indica en la Fig. 3-8(d). Si esas sE/S peticiones se llevan a cabo en ese orden, 
los 
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grafios de recursos resultantes son los que se muestran en la Fig. 3-8(e)-Q). Después de hacerse la petición 
4, A se bloquea esperando S, como se aprecia en la Hg. 3-8(h). En los dos pasos B y C siguientes también 
se bloquean, dando lugar en última instancia a un ciclo y al bloqueo mutuo de la Fig. 3-8(j). 

Sin embargo, como ya hemos mencionado, el sistema operativo no está obligado a ejecutar los 
procesos en un orden específico. En particular, si la concesión de una petición determinada pudiera dar pie 
a un bloqueo mutuo, el sistema operativo podrá simplemente suspender el proceso sin dar respuesta a la 
petición (o sea, no planificar el proceso) hasta que pueda hacerlo sin peligro. En la Hg. 3-8, si el sistema 
operativo tiene conocimiento de un bloqueo mutuo inminente, podría suspender B en lugar de otorgarle S. 
Al ejecutarse sólo A y C obtendríamos las peticiones y liberaciones de la Fig. 3-8(k) en lugar de las de la 
Hg. 3-8(d). Esta secuencia da lugar a los grafos de recursos de la Hg. 3-8(l)-(q), que no conducen a 
bloqueo mutuo. 

Después del paso (q), ya se puede otorgar S a B porque A ya terminó y C tiene todo lo que necesita. 
Incluso si B llegara a bloquearse al solicitar T, no podría ocurrir un bloqueo mutuo. B simplemente 
esperará hasta que C ter mi ne. 

Más adelante en el capítulo estudiaremos un algoritmo detallado para tomar decisiones de 
asignación que no conducen a bloqueos mutuos. Lo que es importante entender ahora es que los grafos de 
recursos son una herramienta que nos permite ver si una secuencia de petición./libera ción dada conduce o 
no al bloqueo. Basta con indicar las peticiones y liberaciones paso por paso, determinando después de 
cada paso si el grafo contiene ciclos. Si los contiene, tenemos un bloqueo mutuo; si no, no hay bloqueo. 
Aunque nuestro tratamiento de los grafos de recursos corresponde al caso en que sólo hay un recurso de 
cada tipo, es posible generalizar los grafos para manejar múltiples recursos del mismo tipo (Holt, 1972). 

En general, son cuatro las estrategias que se emplean para manejar el bloqueo mutuo: 

1. Simplemente hacer caso omiso del problema. 

2. Detección y recuperación. 

3. Evitarlo de manera dinámica, mediante una asignación cuidadosa de los recursos. 

4. Prevención, negando estructuralmente una de las cuatro condiciones necesarias. Examinaremos 
cada uno de estos métodos por tumo en las siguientes cuatro secciones. 


3.3.3 El algoritmo del avestruz 

La estrategia más sencilla es el algoritmo del avestruz: meter la cabeza en la arena y pretender que el 
problema no existe. La gente reacciona a esta estrategia de diversas maneras. Los matemáticos la 
encuentran totalmente inaceptable y dicen que los bloqueos mutuos deben prevenirse a toda costa. Los 
ingenieros preguntan con qué frecuencia se espera que se presente el problema, qué tan seguido se cae el 
sistema por otras razones, y qué tan grave es un bloqueo mutuo. Si ocurren bloqueos mutuos una vez cada 
50 años en promedio, pero las caídas del sistema debido a fallas de hardware, errores del compilador y 
defectos del sistema operativo ocurren una vez al mes, la mayoría de los ingenieros no estarían dispuestos 
a pagar un precio sustancial en términos de reducción del rendimiento o de la comodidad a fin de evitar 
los bloqueos mutuos. 
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Para hacer este contraste más específico, UNIX (y MINIX) sufren potencialmente de bloqueos 
mutuos que ni siquiera se detectan, o mucho menos que se rompan automáticamente. El número total de 
procesos que hay en el sistema está determinado por el número de entradas de la tabla de procesos, así que 
las ranuras de la tabla de procesos son un recurso finito. Si un FORK falla porque la tabla está llena, una 
estrategia razonable para el programa que ejecuta el FORK sería esperar un tiempo aleatorio e intentarlo 
otra vez. 

Supongamos ahora que un sistema UNIX tiene 100 ranuras para procesos. Se están ejecutando 10 
programas, cada uno de los cuales necesita crear 12 (sub)procesos. Una vez que cada proceso ha creado 9 
procesos, los 10 procesos originales y los 90 nuevos han agotado la tabla. 

Ahora, cada uno de los 10 procesos originales se encuentra en un ciclo infinito en el que se bifurcan 
y fallan: bloqueo mutuo. La probabilidad de que esto suceda es pequeñísima, pero podría suceder. 
¿Deberemos abandonar los procesos y la llamada FORK para eliminar el problema? 

El número máximo de archivos abiertos está restringido de forma similar por el tamaño de la tabla 
de nodos-i, así que ocurre un problema similar cuando la tabla se llena. El espacio de intercambio 
(swapping) en el disco es otro recurso limitado. De hecho, casi todas las tablas del sistema operativo 
representan un recurso finito. ¿Debemos cancelar todos estos recursos porque podría suceder que una 
colección de n procesos solicitara un del total, y luego cada uno tratara de adquirir uno más? 

La estrategia de UNIX consiste en hacer caso omiso del problema bajo el supuesto de que la 
mayoría de los usuarios preferirán un bloqueo mutuo ocasional en lugar de una regla que restrinja a todos 
los usuarios a un proceso, un archivo abierto, y una de cada cosa. Si los bloqueos mutuos pudieran 
eliminarse gratuitamente, no habría mucho que discutir. El problema es que el precio es alto, y 
principalmente consiste en poner restricciones molestas a los procesos, como veremos en breve. Así, 
enfrentamos un desagradable trueque entre comodidad y correción, y mucha disco sión acerca de qué es 
más importante. 


3.3.4 Detección y recuperación 

Una segunda técnica es la detección y recuperación. Cuando se usa esta técnica, el sistema no hace otra 
cosa que no sea vigilar las peticiones y liberaciones de recursos. Cada vez que un recurso se solicita o 
libera, se actualiza el grafo de recursos, y se determina si contiene algún ciclo. Si se encuentra uno, se 
ter mi na uno de los procesos del ciclo. Si esto no rompe el bloqueo mutuo, se termina otro proceso, 
continuando así hasta romper el ciclo, Un método un tanto más burdo consiste en no mantener siquiera el 
grafo de recursos, y en vez de ello verificar periódicamente si hay procesos que hayan estado bloqueados 
continuamente durante más de, digamos, una hora. A continuación se ter mi nan esos procesos. 

La detección y ecuperación es la estrategia que a menudo se usa en las macrocomputadoras, sobre 
todo los sistemas por lotes en los que terminar y luego reiniciar un proceso suele ser aceptable. Sin 
embargo, se debe tener cuidado de restaurar todos los archivos modificados a su estado original, y revertir 
todos los demás efectos secundarios que pudieran haber ocurrido. 
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3.3.5 Prevención del bloqueo mutuo 

La tercera estrategia para manejar el bloqueo mutuo consiste en imponer restricciones apropiadas abs 
procesos de modo que el bloqueo mutuo sea estructuralmente imposible. Las cuatro condiciones 
planteadas por Coffman et al. (1971) señalan algunas posibles soluciones. Si podemos asegurar que al 
menos una de esas condiciones nunca se satisfaga, el bloqueo mutuo será imposi ble (Havender, 1968). 

Ataquemos primero la condición de exclusión mutua. Si ningún recurso se asignara de manera 
exclusiva a un solo proceso, jamás tendríamos bloqueo mutuo. Sin embargo, es igualmente obvio que 
permitir a dos procesos escribir en la impresora al mismo tiempo conduciría al caos. Si colocamos en 
spool las salidas a la impresora, varios procesos podrán generar salidas al mismo tiempo. En este modelo, 
el único proceso que realmente solicita la impresora física es el demonio de la impresora. Puesto que el 
demonio nunca solicita otros recursos, podemos eliminar el blo queo mutuo para la impresora. 

Desafortunadamente, no todos los recursos se pueden manejar con spool (la tabla de procesos no se 
presta muy bien que digamos a ello). Además, la competencia misma por obtener espacio de disco para 
spool puede dar lugar al bloqueo. ¿Qué sucedería si dos procesos llenaran cada uno con sus salidas la 
mitad del espacio de spool disponible y ninguno terminara? Si el demonio se progra mara de modo que 
comenzara a imprimir antes de que toda la salida estuviera en spool, la impre sora podría permanecer 
ociosa si un proceso de salida decidiera esperar varias horas después de la primera ráfaga de salida. Por 
esta razón, los demonios se programan de modo que sólo impriman si ya está disponible todo el archivo de 
salida. Ninguno de los procesos terminaría, y tendríamos un bloqueo mutuo por el disco. 

La segunda de las condiciones planteadas por Coffman et al. se ve más prometedora. Si pode mos 
evitar que los procesos que retienen recursos esperen para obtener más recursos, podremos eliminar los 
bloqueos mutuos. Una forma de lograr este objetivo es exigir que todos los procesos soliciten todos sus 
recursos antes de iniciar su ejecución. Si todo está disponible, se asignará al proceso todo lo que necesita y 
éste podrá ejecutarse hasta finalizar. Si uno o más recursos están ocupados, no se asignará nada y el 
proceso simplemente esperará. 

Un problema inmediato de esta estrategia es que muchos procesos no saben cuántos recur sos van a 
necesitar antes de iniciar su ejecución. Otro problema es que los recursos no se aprovecha rán de manera 
óptima. Tomemos como ejemplo un proceso que lee datos de una cinta de entrada, los analiza durante una 
hora, y luego escribe una cinta de salida y además gráfica los resultados. Si todos los recursos se 
solicitaran por adelantado, el proceso mantendría inaccesibles la unidad de cinta de salida y el graficador 
durante una hora. 

Una forma un poco distinta de romper la condición de retener y esperar es exigir que un proceso que 
solicita un recurso libere primero temporalmente todos los recursos que está rete niendo en ese momento. 
Sólo si la petición tiene éxito podrá el proceso recibir de vuelta los recursos originales. 

Atacar la tercera condición (no expropiación) es aún menos prometedor que atacar la 
segunda. Si a un proceso se le asignó la impresora y apenas ha imprimido la mitad de sus salidas, 
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quitarle forzosamente la impresora porque un graficador que se necesita no está disponible daría lugar a 
un desastre. 

Sólo queda una condición. Se puede eliminar la espera circular de varias formas. Una de ellas 
consiste sencillamente en tener una regla que diga que un proceso sólo tiene derecho a un solo recurso en 
un instante dado. Si el proceso necesita un segundo recurso, deberá liberar el primero. Para un proceso que 
necesita copiar un archivo enorme de una cinta a una impresora, esta restricción es inaceptable. 

Otra forma de evitar la espera circular es crear una numeración global de todos los recursos, como 
se muestra en la Fig. 3-9(a). Ahora la regla es ésta: los procesos pueden solicitar recursos cuando quieran, 
pero todas las peticiones deben hacerse en orden numérico. Un proceso puede solicitar primero una 
impresora y después una unidad de cinta, pero no puede solicitar primero un graficador y luego una 
impresora. 


1 CD-ROM 
2. Impresora 

3 Graficador 

4 Unidad de cmta 

5 Brazo robot 


(a) 


(b) 


Figura 3-9. (a) Recursos ordenados numéricamente, (b) Un grafo de recursos. 


Con esta regla, el grafo de asignación de recursos nunca puede tener ciclos. Veamos por qué esto se 
cumple para el caso de dos procesos [Fi.g 3-9(b)] Podemos tener un bloqueo mutuo sólo si A solicita el 
recurso j y B solicita el recurso i. Si suponemos que i y j son recursos distintos, tendrán diferente número. 
Si i >1, no se permitirá a A solicitar j. Si i <j, no se permitirá a B solicitar i. De cualquier manera, el 
bloqueo mutuo es imposible. 

La misma lógica es válida para múltiples procesos. En todo instante, uno de los recursos asignados 
será el más alto. El proceso que esté reteniendo ese recurso nunca podrá solicitar uno que ya está 
asignado; o bien finalizará, o en el peor de los casos solicitará recursos con un número aún más alto, todos 
los cuales están disponibles. Tarde o temprano, ese proceso finalizará y liberará sus recursos. En este 
punto, algún otro recurso estará reteniendo el recurso más alto y también podrá finalizar. En pocas 
palabras, existe una situación en la que todos los procesos terminan, de modo que no hay bloqueo mutuo. 

Una variación menor de este algoritmo consiste en o mi tir el requisito de que los recursos se 
adquieran en orden estrictamente creciente y sólo insistir en que ningún proceso solicite un recurso con un 
número menor que el del recurso que ya tiene en su poder. Si un proceso inicial- mente solicita los 
recursos 9 y 10, y luego los libera, en efecto estará de nuevo iniciando desde el principio, y no habrá razón 
para prohibirle ahora que solicite el recurso 1. 

Aunque el ordenamiento numérico de los recursos elimina el problema de los bloqueos 
mutuos, puede ser imposible encontrar un ordenamiento que satisfaga a todo mundo. Cuando 
los recursos incluyen ranuras de la tabla de procesos, espacio de disco para spool, registros de base de 
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datos con candado y otros recursos abstractos, el número de recursos potenciales y de posibles usos puede 
ser tan grande que ningún ordenamiento resulte práctico. 

En la Fig. 3-10 se resumen las diferentes estrategias para prevenir los bloqueos mutuos. 


i_Condición 

Estrategia 

1 Exclusión mutua 

Poner todo en spool 

Retener y esperar 

Solicitar aiicialmente todos los recursos 

No expropiación 

Quitar los recursos 

Espera circular 

Ordenar los recursos numéricamente 


Figura 3-10. Resumen de estrategias para prevenir el bloqueo mutuo. 


3.3.6 Evitar los bloqueos mutuos 

En la Fig. 3-8 vimos que el bloqueo mutuo se evitaba no imponiendo reglas arbitrarias a los procesos sino 
analizando con detenimiento cada petición de recurso para ver si se puede satisfa cer sin peligro. Surge la 
pregunta: ¿hay algún algoritmo que siempre pueda evitar el bloqueo mutuo tomando la decisión correcta 
en todos los casos? La respuesta es que sí se puede evitar el bloqueo mutuo, pero sólo si se cuenta con 
cierta i nf ormación por adelantado. En esta sección exa mi naremos formas de evitar los bloqueos mutuos 
mediante una asignación cuidadosa de los recursos. 


El algoritmo del banquero para un solo recurso 

Un algoritmo de planificación que puede evitar el bloqueo mutuo se debe a Dijkstra (1965) y se conoce 
como algoritmo del banquero. Este algoritmo toma como modelo la forma en que un banquero de una 
ciudad pequeña podría tratar con un grupo de clientes a los que ha concedido líneas de crédito. En la Fig. 
3-li(a) vemos cuatro clientes, a cada uno de los cuales se ha otorgado cierto número de unidades de crédito 
(p. ej., 1 unidad = 1K dólares). El banquero sabe que no todos los clientes van a necesitar su crédito 
máximo de inmediato, así que sólo ha reservado 10 unidades en lugar de 22 para atenderlos, (En esta 
analogía, los clientes son procesos, las unidades de crédito son, digamos, unidades de cinta, y el banquero 
es el sistema operativo.) 

Los clientes atienden sus respectivos negocios, haciendo peticiones de préstamos de vez en cuando. 
En un momento dado, la situación es la que se muestra en la Fig. 3-1 l(b). Una lista de los clientes junto 
con el dinero que ya se les prestó (unidades de cinta que ya se les asignaron) y el crédito máximo 
disponible (número máximo de unidades de cinta que se necesitarán al mismo tiempo posteriormente) se 
denomina estado del sistema respecto a la asignación de recursos. 

Se dice que un estado es seguro si existe una secuencia de otros estados que conduzca a una situación 
en la que todos los clientes obtienen préstamos hasta sus límites de crédito (todos los procesos 
obtienen todos sus recursos y finalizan). El estado de la Fig. 3-1 l(b) es seguro porque, 
quedándole dos unidades, el banquero puede posponer todas las peticiones excepto la de Miguel, 











176 


ENTRAD A/SALIDA 


CAP. 3 



(a) 


(b) 


(c) 


Figura 3-11. Tres estados de asignación de recursos: (a) Seguro, (b) Seguro, (c) Inseguro. 


de modo que dejará que éste finalice y libere sus cuatro recursos. Teniendo cuatro recursos disponibles, el 
banquero puede otorgar a Susana o a Bárbara las unidades que necesiten, etcétera. 

Consideremos lo que sucedería si se concediera a Bárbara una unidad más en la Fig. 3-1 l(b); 
tendríamos la situación de la Fig. 3-11 (c) que es insegura. Si todos los clientes pidieran repentina mente 
sus préstamos máximos, el banquero no podría satisfacer ninguna de sus peticiones, y tendríamos un 
bloqueo mutuo. Un estado inseguro no tiene que dar pie al bloqueo mutuo, ya que un cliente podría no 
necesitar toda su línea de crédito disponible, pero el banquero no puede contar con que esto sucederá. 

Por tanto, el algoritmo del banquero consiste en considerar cada petición en el momento en que se 
presenta y ver si su satisfacción conduce o no a un estado seguro. Si es así, se concede lo solicitado; si no, 
se pospone la petición. Para determinar si un estado es seguro, el banquero verifica si tiene suficientes 
recursos para satisfacer al cliente que está más cerca de su máximo. Si los tiene, se supone que esos 
préstamos ya fueron pagados, y a continuación se verifica el cliente que ahora está más cerca de su límite, 
y así sucesivamente. Si todos los préstamos pueden pagarse tarde o temprano, el estado es seguro y puede 
satisfacerse la petición in icial. 


Trayectorias de recursos 

El algoritmo anterior se describió en términos de una sola clase de recursos (p. ej., sólo unidades de cinta 
o sólo impresoras, pero no algunas de cada clase). En la Fig. 3-12 vemos un modelo para manejar dos 
procesos y dos recursos, por ejemplo, una impresora y un graficador. El eje horizontal representa el 
número de instrucciones ejecutadas por el proceso A. El eje vertical representa el número de instrucciones 
ejecutadas por el proceso B. En IA solicita una impresora; en ‘2’ A necesita un graficador. La impresora y 
el graficador son liberados en 13 e 14, respectivamente. El proceso J necesita el graficador de 15 a 17, y la 
impresora, de ‘6 a 18. 

Cada punto del diagrama representa un estado conjunto de los dos procesos. Inicialmente, 
el estado está en p, donde ningún proceso ha ejecutado todavía instrucciones. Si el planificador 
decide ejecutar A primero, llegamos al punto q, en el que A ya ejecutó cierto número 
de instrucciones, pero Ji todavía no ejecuta ninguna. En el punto q la trayectoria se vuelve vertical, lo que 
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indica que el planificador decidió ejecutar B. Con un solo procesador, todas las trayectorias deben ser 
horizontales o verticales, nunca diagonales. Además, el movimiento siempre es hacia el norte o hacia el 
este, nunca hacia el sur o hacia el oeste (los procesos no pueden ejecutarse hacia atrás). 

Cuando A cruza la línea I en la trayectoria de r a s, solicita y recibe la impresora. Cuando B llega al 
punto t, solicita el graficador. 

Las regiones sombreadas son de especial interés. La región con líneas inclinadas del suroeste al 
noreste indican que ambos procesos tienen la impresora. La regla de exclusión mutua hace que sea 
imposible entrar en esta región. De forma similar, la región sombreada en la otra dirección indica que 
ambos procesos tienen el graficador, y es igualmente imposible. 

Si el sistema alguna vez entra en el cuadro delimitado por 1 e ‘2 a los lados e 15 e ‘6 de arriba a 
abajo, nos encontraremos ante un bloqueo mutuo cuando llegue a la intersección de ‘2 e 16. En este punto, 
A está solicitando el graficador y B está solicitando la impresora, y ambos dispositivos ya están asignados. 
Todo el cuadro es inseguro y no debe entrarse en él. En el punto ¿t lo único seguro es ejecutar el proceso 
A hasta que llegue a 14. De ahí en adelante, cualquier trayectoria a u es buena. 


El algoritmo del banquero para múltiples recursos 

Este modelo gráfico es difícil de aplicar al caso general de un número arbitrario de procesos y un número 
arbitrario de clases de recursos, cada una con múltiples ejemplares (p. ej., dos graficadores, tres unidades 
de cinta). No obstante, el algoritmo del banquero puede generalizarse para este fin. En la Fig. 3-13 se 
muestra cómo fúnciona. 

En la figura vemos dos matrices. La de la izquierda muestra cuántos ejemplares de cada 
recurso se han asignado actualmente a cada uno de los cinco procesos. La matriz de la 
derecha muestra cuántos recursos necesita todavía cada proceso para poder finalizar. Al igual que en el 
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E - (6342) 
P - (5322) 
A > (1020) 


Rwxirm que se wcettan 


Figura 3-13. El algoritmo del banquero con múltiples recursos. 


caso de un solo recurso, los procesos deben expresar sus necesidades de recursos totales antes de 
ejecutarse, a fin de que el sistema pueda calcular la matriz de la derecha en cada paso. 

Los tres vectores a la derecha de la figura muestran los recursos existentes, E, los recursos poseídos, 
P y los recursos disponibles, A, respectivamente. Por E podemos ver que el sistema tiene sE/S unidades de 
cinta, tres graficadores, dos impresoras y dos unidades de CD-ROM. De éstos, cinco unidades de cinta, 
tres graficadores, dos impresoras y dos unidades de CD-ROM están asignados actualmente. Esto puede 
verse sumando las cuatro columnas de recursos en la matriz de la izquierda. El vector de recursos 
disponibles es simplemente la diferencia entre lo que el sistema tiene y lo que se está usando actualmente. 

Ahora podemos plantear el algoritmo para verificar si un estado es seguro o no. 

1. Busque una fila, R, cuyas peticiones de recursos no se hayan otorgado y sean en todos los casos 
menores que o iguales a A. Si no existe tal fila, el sistema tarde o temprano llegará a un bloqueo mutuo 
porque ningún proceso podrá ejecutarse has ta finali z ar. 

2. Suponga que el proceso de la fila elegida solicita todos los recursos que necesita (lo cual se 
garantiza que es posible) y finaliza. Marque ese proceso como terminado y agregue todos sus recursos al 
vector A. 

3. Repita los pasos 1 y 2 hasta que todos los procesos se marquen como terminados, en cuyo caso el 
estado inicial era seguro, o hasta que ocurra un bloqueo mutuo, en cuyo caso no lo era. 

Si hay varios procesos que pueden escogerse en el paso 1, no importa cuál se seleccione: la reser va de 
recursos aumentará o, en el peor de los casos, seguirá igual. 

Volvamos ahora al ejemplo de la Fig. 3-13. El estado actual es seguro. Supongamos ahora que el 
proceso B solicita una impresora. Esta petición puede satisfacerse porque el estado resultante sigue siendo 
seguro (el proceso D puede finalizar, y luego el proceso A o E, seguidos por el resto). 

Imaginemos ahora que después de otorgarle a B una de las dos impresoras restantes 
E quiere la última impresora. La concesión de ese recurso reduciría el vector de recursos disponibles a 
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(1 O O 0), lo que conduce a un bloqueo mutuo. Es evidente que no se puede satisfacer por ahora la petición 
de E y deberá posponerse durante un rato. 

Este algoritmo fue publicado por Dijkstra en 1965. Desde entonces, casi todos los libros sobre 
sistemas operativos lo han descrito detalladamente y se han escrito i nn umerables artículos acerca de 
diversos aspectos de él. Desafortunadamente, pocos autores han tenido la audacia de señalar que, si bien 
en teoría el algoritmo es maravilloso, en la práctica es casi inútil porque los wocesos casi nunca saben por 
adelantado cuáles serán sus necesidades de recursos máximas. Además, el número de procesos no es fijo, 
sino que varía dinámicamente conforme los usuarios inician y terminan tareas. Por añadidura, los recursos 
que se creía estaban disponibles pueden desaparecer repentinamente (las unidades de cinta pueden 
descomponerse). 

En síntesis, los esquemas que hemos descrito dentro del rubro de “prevención” son demasía do 
restrictivos, y el algoritmo que se describió como de “evitación” requiere in formación que, por lo regular 
no está disponible. Si a usted se le ocurre un algoritmo de propósito general que realice el trabajo tanto en 
teoría como en la práctica, escn’balo y envíelo a su publicación local sobre ciencias de la computación. 

Para aplicaciones específicas, se conocen muchos algoritmos excelentes. Por ejemplo, en muchos 
sistemas de bases de datos una operación que ocurre con frecuencia es la petición de candados para varios 
registros seguida de la actualización de todos los registros asegurados. Cuando se ejecutan varios procesos 
al mismo tiempo, el peligro de que ocurra un bloqueo mutuo es muy real. 

La estrategia que suele usarse es la de candados de dos fases. En la primera fase, el proceso trata de 
asegurar todos los registros que necesita, uno por uno. Si lo logra, realiza sus actualiza ciones y libera los 
candados. Si algún registro ya está asegurado, el proceso libera los candados que había adquirido y 
comienza otra vez. En cierto sentido, este enfoque es similar a solicitar todos los recursos que se necesitan 
por adelantado, o al menos antes de hacer algo irreversible. 

Sin embargo, tal estrategia no es aplicable en general. Por ejemplo, en los sistemas de tiempo real y 
en los de control de procesos, no es aceptable terminar simplemente un proceso a la mitad porque un 
recurso no esté disponible, y comenzar otra vez desde el principio. Tampoco es acep table comenzar otra 
vez si el proceso ha leído mensajes de la red o enviado mensajes por ella, si ha actualizado archivos o si ha 
hecho alguna otra cosa que no pueda repetirse sin peligro. El algorit mo sólo funciona en los casos en los 
que el programador ha dispuesto las cosas cuidadosamente de modo que el programa pueda detenerse en 
cualquier momento durante la primera fase y reiniciarse. Desafortunadamente, no todas las aplicaciones 
pueden estructurarse de esta manera. 


3.4 GENERALIDADES DE E/S EN MINIX 

La E/S en MINIX tiene la estructura que se muestra en la Fig. 3-6. Las cuatro capas superiores de esa 
figura corresponden a la estructura de cuatro capas de MINIX que se muestra en la Fig. 2-26. 
En las siguientes secciones daremos un vistazo a cada una de las capas, haciendo hincapié 
en los controladores de dispositivos. El manejo de interrupciones ya se estudió en el capítulo anterior, 
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y la E/S independiente del dispositivo se verá cuando lleguemos al sistema de archivos, en el capítulo 5. 


3.4.1 Manejadores de interrupciones en MÍNÍX 

Muchos de los controladores de dispositivos inician algún dispositivo de E/S y luego se bloquean en 
espera de que llegue un mensaje. Ese mensaje por lo regular es generado por el manejador de 
interrupciones que corresponde a ese dispositivo. Otros controladores de dispositivos no inician una E/S 
física (p. ej., la lectura de un disco en RAM y la escritura en una pantalla mapeada en memoria), no usan 
interrupciones y no esperan un mensaje de un dispositivo de E/S. En el capítulo anterior presentamos con 
gran detalle el mecanismo mediante el cual las interrupciones generan mensajes y causan conmutaciones 
de tareas, y no hablaremos más de él aquí. Sin embargo, los manejadores de interrupciones pueden hacer 
algo más que generar mensajes; en muchos casos también realizan cierto procesamiento de las entradas y 
salidas en el nivel más bajo. Describiremos esto de forma general aquí y luego veremos los detalles 
cuando estudiemos el código para diversos dispositivos. 

En el caso de los dispositivos de disco, las entradas y salidas generalmente implican ordenar a un 
dispositivo que realice su operación, y luego esperar hasta que se finaliza la operación. El controlador en 
hardware del disco realiza casi todo el trabajo, y poco se exige al manejador de interrupciones. Ya vimos 
que el manejador de interrupciones completo para la tarea del disco duro consiste en sólo tres líneas de 
código, y la única operación de E/S es la lectura de un solo byte para determinar el estado del controlador 
en hardware. Las cosas serían en verdad sencillas si todas las interrupciones pudieran manejarse con tanta 
facilidad. 

En otros casos el manejador de bajo nivel tiene más cosas que hacer. El mecanismo de 
transferencia de mensajes tiene un costo. Si una interrupción puede ocurrir con frecuencia pero la cantidad 
de E/S que se maneja por interrupción es pequeña, puede ser costeable hacer que el manejador mismo 
realice un poco más de trabajo y posponga el envío de un mensaje a la tarea hasta una interrupción 
subsecuente, cuando la tarea tenga algo más que hacer. MINIX maneja de este modo las interrupciones del 
reloj. En muchos tics del reloj no hay mucho que hacer, con excepción de mantener la hora. Esto puede 
hacerse sin enviar un mensaje a la tarea del reloj misma. El manejador del reloj incrementa una variable 
llamada pendingticks (tics pendientes). La hora actual es la suma de la hora registrada la última vez que 
se ejecutó la tarea del reloj más el valor de pending ticks. Cuando la tarea del reloj recibe un mensaje y se 
despierta, suma pending ticks a su variable principal para llevar la hora y luego pone en ceros 
pending ticks. El manejador de interrupciones del reloj examina algunas otras variables y sólo envía un 
mensaje a la tarea del reloj cuando detecta que ésta tiene trabajo real que efectuar, como entregar una 
alarma o planificar la ejecución de un nuevo proceso. El manejador también podría enviar un mensaje a la 
tarea de la terminal. 

En la tarea de la term in al vemos otra variación del tema de los manejadores de interrupciones. 
Esta tarea maneja varios tipos de hardware distintos, incluido el teclado y las líneas RS-232. 
Cada uno de éstos tiene su propio manejador de interrupciones. El teclado se ajusta perfectamente 
a la descripción de un dispositivo en el que puede haber relativamente poca E/S que realizar en respuesta 
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a cada interrupción. En una PC ocurre una interrupción cada vez que se oprime o se suelta una tecla. Esto 
incluye teclas especiales como SHIFT y CTRL, pero si nos olvidamos de ellas por el momento, podemos 
decir que, en promedio, se recibe medio carácter por interrupción. Puesto que no hay mucho que la 
terminal pueda hacer con medio carácter, parece sensato enviarle un mensaje sólo cuando pueda lograrse 
algo que valga la pena. Examinaremos los detalles más adelante; por ahora sólo diremos que el manejador 
de interrupciones del teclado realiza la lectura de bajo nivel de los datos del teclado y luego elimina los 
eventos que puede ignorar, como la liberación de una tecla ordinaria. (La liberación de una tecla especial, 
como SHIFT, no puede ignorarse.) Luego se colocan en una cola códigos que representan todos los 
eventos no ignorados para que sean procesados posteriormente por la tarea de la ter mi nal misma. 

El manejador de interrupciones del teclado difiere del sencillo paradigma que hemos presen tado del 
manejador de interrupciones que envía un mensaje a la tarea a la que está asociado, porque este manejador 
de interrupciones no envía mensajes. En su lugar, cuando el manejador agrega un código a la cola, 
modifica una variable ttytimeout, que es leída por el manejador de interrupciones del reloj. Si una 
interrupción no modifica la cola, tampoco se modifica tlytimeout. En el siguiente tic del reloj el 
manejador del reloj envía un mensaje a la tarea de terminal si la cola se ha modificado. Otros manejadores 
de interrupciones tipo terminal, como los de las líneas RS- 232, funcionan del mismo modo. La tarea déla 
terminal recibe un mensaje poco tiempo después de que se recibe un carácter, pero no se genera 
necesariamente un mensaje por cada carácter cuando los caracteres llegan rápidamente. Pueden 
acumularse varios caracteres y luego ser pro cesados como respuesta a un solo mensaje. Además, todos 
los dispositivos de terminal se revisan cada vez que la tarea de terminal recibe un mensaje. 


3.4.2 Controladores de dispositivos en MINIX 

Para cada clase de dispositivo de E/S presente en un sistema MINIX hay una tarea de E/S (controlador de 
dispositivo) individual. Estos controladores son procesos con todas las de la ley, cada uno con su propio 
estado, registros, pila, etc. Los controladores de dispositivos se comunican entre sí (si es necesario) y con 
el sistema de archivos usando el mecanismo de transferencia de mensajes estándar que utilizan todos los 
procesos de MINIX. Los controladores de dispositivos sencillos se escriben como archivos fuente únicos, 
por ejemplo clock.c. En el caso de otros controladores, como los del disco en RAM, el disco duro y el 
disco flexible, hay un archivo fuente para manejar cada tipo de dispositivo, además de un conjunto de 
rutinas comunes contenidas en drive que apoyan todos los tipos de hardware distintos. En cierto sentido 
esto divide el nivel de controladores de dispositivos de la Fig. 3-6 en dos subniveles. Esta separación de 
las partes del software dependiente del hardware e independiente del hardware facilita la adaptación a una 
diversidad de configuraciones de hardware diferentes. Aunque se usa algo de código fuente común, el 
controlador para cada tipo de disco se ejeduta como proceso aparte, con objeto de realizar transferencias 
de datos rápidas. 

El código fúente del controlador de ter mi nal está organizado de forma similar, con 
el código independiente del hardware en uy.c y el código fuente para apoyar diferentes dispositivos, 
como las consolas con mapa en memoria, el teclado, las líneas en serie y las seudoterminales, en archivos 
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individuales. Sin embargo, en este caso, un solo proceso apoya todos los diferentes tipos de dispositivos. 

En el caso de grupos de dispositivos como los discos y terminales, para los cuales hay varios 
archivos fuente, también hay archivos de cabecera. Drive,:h apoya todos los controladores de dispositivos 
por bloques. Tty.h provee definiciones comunes para todos los dispositivos de terminal. 

La diferencia principal entre los controladores de dispositivos y otros procesos es que los primeros 
se enlazan juntos en el kemel, y, por tanto, todos comparten el mismo espacio de direcciones. En 
consecuencia, si varios controladores de dispositivos utilizan un procedimiento común, sólo se enlazará 
una copia en el binario de MINIX. 

Este diseño es altamente modular y moderadamente eficiente; también es uno de los pocos lugares 
en los que MINIX difiere de UNIX de una forma esencial. En MINIX un proceso lee un archivo enviando 
un mensaje al proceso del sistema de archivos. Éste, a su vez, puede enviar un mensaje al controlador de 
dispositivo pidiéndole que lea el bloque requerido. Esta secuencia (un poco simplificada respecto a la 
realidad) se muestra en la Fig. 3-14(a). Al llevar a cabo estas interacciones a través del mecanismo de 
mensajes, obligamos a varias partes del sistema a comu nicarse de forma estándar con otras partes. No 
obstante, al colocar todos los controladores de dispositivos en el espacio de direcciones del kemel les 
permitimos tener acceso fácil a la tabla de procesos y a otras estructuras de datos clave cuando es 
necesario. 
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El sistema de archivos llama 
al controlador de dispositivo 
como procedimiento Todo 
el sistema operativo forma 
parte de cada proceso 
(b) 


Figura 3-14. Dos formas de estructurar la comunicación usuario sistema. 


En UNIX todos los procesos tienen dos partes: una parte de espacio de usuario y una parte 
de espacio del kemel, como se aprecia en la Fig. 3-14(b). Cuando se efectúa una llamada al sistema, 
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el sistema operativo conmuta de la parte de espacio de usuario a la parte de espacio del kemel de una 
forma un tanto mágica. Esta estructura es una reliquia del diseño de MULTICS, en el que la conmutación 
era sólo una llamada ordinaria al sistema, no una trampa seguida por el almacena miento del estado de la 
parte de usuario, como en UNIX. 

Los controladores de dispositivos en UNIX son simplemente procedimientos del kemel invocados 
por la parte de espacio del kemel del proceso. Cuando un controlador necesita esperar una interrupción, 
invoca un procedimiento del kemel que lo pone a dormir hasta que algún manejador de interrupciones lo 
despierta. Observe que es el proceso de usuario mismo el que se pone a dormir aquí, porque las partes del 
kemel y del usuario son en realidad partes distintas del mismo proceso. 

Entre los diseñadores de sistemas operativos son interminables los debates acerca de las ventajas 
relativas de los sistemas monolíticos, como UNIX, y los sistemas estructurados por procesos, como 
MINIX. El enfoque de MINIX está mejor estructurado (es más modular), tiene interfaces más limpias 
entre los componentes y se extiende fácilmente a los sistemas distribuidos en los que los diversos procesos 
se ejecutan en diferentes computadoras. El enfoque de UNIX es más eficiente, porque las llamadas a 
procedimientos son mucho más rápidas que el envío de mensajes. MINIX se dividió en muchos procesos 
porque creemos que, con la aparición de computadoras personales cada vez más potentes, se justifica 
hacer un poco más lento el sistema en aras de tener una estructura de software más clara. Cabe señalar que 
muchos diseñadores de sistemas operativos no comparten esta opinión. 

En este capítulo estudiaremos los controladores para el disco en RAM, el disco duro, el reloj y la 
terminal. La configuración estándar de MINLX también incluye controladores para disco flexible e 
impresora, que no explicaremos detalladamente. La distribución de software de MINIX contiene código 
fuente de controladores adicionales para líneas en serie RS-232, una interfaz SCSI, CD ROM, adaptador 
Ethernet y tarjeta de sonido. Éstos pueden incluirse recompilando MINIX. 

Todas estas tareas se comunican con otras partes del sistema MINIX de la misma forma: se envían 
mensajes de petición a las tareas. Los mensajes contienen diversos campos que contienen el código de 
operación (p. ej., READ o WRITE) y sus parámetros. La tarea intenta satisfacer una petición y devuelve 
un mensaje de respuesta. 

En el caso de los dispositivos por bloques, los campos de los mensajes de petición y respuesta son 
los que se muestran en la Fig. 3-15. El mensaje de petición incluye la dirección de un área de 
almacenamiento intermedio que contiene los datos que se van a trans mi tir o en la que se esperan los datos 
recibidos. La respuesta incluye información de estado que permite al proceso solicitante verificar que su 
petición se llevó a cabo correctamente. Los campos para los dispositivos por caracteres son similares pero 
pueden variar un poco de una tarea a otra. Los mensajes dirigidos a la tarea del reloj, por ejemplo, 
contienen tiempos, y los mensajes a la tarea de terminal pueden contener la dirección de una estructura de 
datos que especifica todos los múltiples aspectos configurables de una terminal, como los caracteres que 
se usarán para las funciones de edición intralínea borrar-carácter y eli mi nar-l ín ea. 

La función de cada tarea es aceptar peticiones de Otros procesos, normalmente el sistema 
de archivos, y llevarlas a cabo. Todas las tareas de los dispositivos por bloques se escribieron de 
modo que obtienen un mensaje, lo llevan a cabo y envían una respuesta. Entre otras cosas, esta 
decisión implica que tales tareas son estrictamente secuenciales y no contienen multiprogramación interna, 
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Peticiones 

Campo 

Tipo 

Significado 

i m m type 

Int 

Operación solicitada 

1 m DEVICE 

int 

Dispositivo secundario a usar 

m PROC NR 

int 

Proceso que solicita la E/S 

m.COUNT 

int 1 

^ Cuenta de bytes o código ¡octl 

m.POSITION 

tong 

| Posición en «I dispositivo 

m.ADDRESS [ char* 

Dirección dentro del proceso solicitante 



Figura 3-15. Campus de los mensajes enviados por el sistema de archivos a los controladores 
de dispositivos por bloques y campos de las respuestas devueltas. 


a fin de mantenerlas sencillas. Cuando se emite una petición de hardware, la tarea ejecuta una operación 
RECEIVE especificando que sólo le interesa aceptar mensajes de interrupción, no nuevas peticiones de 
trabajo. Cualesquier mensajes de petición nuevos que lleguen se mantendrán espe rando hasta que se haya 
finalizado el trabajo en curso (principio de cita). La tarea de term in al es un poco diferente, ya que una sola 
tarea da servicio a varios dispositivos. Así, es posible aceptar una nueva petición de entrada del teclado 
mientras se está atendiendo una petición de lectura de una línea serial. No obstante, para cada dispositivo 
se debe finalizar una petición antes de iniciar una nueva. 

Estructuralmente, el programa principal para cada controlador de dispositivo por bloques es el 
mismo, y se bosqueja en la Fig. 3-16. Cuando se arranca el sistema, se inicia por tumo cada uno de los 
controladores para darles la oportunidad de inicializar tablas intemas y cosas por el estilo. Luego, cada 
tarea de controlador se bloquea tratando de obtener un mensaje. Cuando llega un mensaje, se guarda la 
identidad de quien lo originó y se invoca un procedimiento para llevar a cabo el trabajo, invocándose un 
procedimiento distinto para cada operación disponible. Una vez finalizado el trabajo, se devuelve una 
respuesta al originador del mensaje y la tarea regresa al principio del ciclo para esperar la siguiente 
petición. 

Cada uno de los procedimientos dev xxx se encarga de una de las operaciones que puede ejecutar 
el controlador, y devuelve un código de estado para indicar qué sucedió. Este código, que se incluye 
en el mensaje de respuesta como campo REP STATUS, es el número de bytes transfe ridos 
(cero o positivo) si todo salió bien, o el número de error (negativo) si no fúe así. Este 
conteo puede diferir del número de bytes solicitado. Si se llega al final de un archivo, el número de bytes 
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/* buffer del mensaje 7 


voíd io_task() { 

initializeO; /* sólo se hace una vez. al iníclalizar el sistema 7 

wfiíle (TRUE) { 

receive(ANY, &mess); /* esperar una petición de trabajo 7 

callar = mess.source; /* proceso del que vino el mensaje 7 

switch(mess.type) { 

case READ: rcode * dev_read(&mess); break; 

case WRITE. rcode = dev_write(&mess); break; 

r Aquí van otros casos, incluidos OPEN, CLOSE e IOCTL 7 
default: rcode = ERROR; 

} 

mess.type = TASK REPLY; 

mess.status = rcode; r código de resultado 7 

send(caller. &mess); /* enviar mensaje de respuesta al invocador 7 

> 

) 


Figura 3-16. Bosquejo del procedimiento principal de una tarea de E/S. 


disponibles puede ser menor que el número solicitado. En las ter mi nales se devuelve como mucho una 
línea, aunque el número solicitado haya sido mayor. 


3.4.3 Software de E/S independiente del dispositivo en MINIX 

En MINIX el proceso del sistema de archivos contiene todo el código de E/S independiente del 
dispositivo. El sistema de E/S está tan íntimamente relacionado con el sistema de archivos que se 
fúsionaron para formar un solo proceso. Las fúnciones del sistema de archivos son las que se muestran en 
la Fig. 3-5, excepto la petición y liberación de dispositivos de uso exclusivo, que no existen en la 
configuración actual de MINIX. Sin embargo, si surge la necesidad de agregar- los a los controladores de 
dispositivos pertinentes en el futuro, no sería difícil hacerlo. 

Además de manejar la interfaz con los controladores, el almacenamiento intermedio y la asigna ción 
de bloques, el sistema de archivos también se encarga de la protección y administración de los nodos-i, 
directorios y sistemas de archivos montados. Cubriremos este sistema en el capítulo 5. 


3.4.4 Software de E/S de nivel de usuario en MINIX 

El modelo general que bosquejamos antes en este capítulo también tiene aplicación aquí. Hay 
procedimientos de biblioteca para realizar llamadas al sistema y para todas las funciones de C 
requeridas por el estándar oslx, como las fúnciones de entrada y salida formateadaprintfy 
scanf. La configuración estándar de MINIX contiene un demonio de spool, lpd, que coloca en 
spool e imprime los archivos que se le pasan con el comando ip. La distribución de software estándar de 
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MINIX contiene varios demonios que apoyan diversas funciones de red. Las operaciones de red requieren 
cierto apoyo del sistema operativo que no forma parte de MINIX en la configuración que se describe en 
este libro, pero es fácil recompilar MINIX agregando el servidor de red, el cual se ejecuta con la misma 
prioridad que el administrador de memoria y el sistema de archivos y, al igual que ellos, se ejecuta como 
proceso de usuario. 


3.4.5 Manejo de bloqueos mutuos en MINIX 

Haciendo honor a su herencia, MINIX sigue el mismo camino que UNIX en lo tocante a los 
bloqueosmutuos: simplemente hace caso omiso del problema. MINIX no contiene dispositivos de BIS de 
uso exclusivo, aunque si alguien quisiera conectar una unidad de cinta DAT estándar de la industria a una 
PC, preparar el software para ella no presentaría problemas especiales. En pocas palabras, el único lugar 
en el que pueden ocurrir bloqueos mutuos es en el uso de los recursos compartidos implícitos, como las 
ranuras de la tabla de procesos, las de la tabla de nodos-i, etc. Ninguno de los algoritmos de bloqueo 
mutuo conocidos puede manejar recursos como éstos que no se solicitan explícitamente. 

En realidad, lo anterior no es estrictamente cierto. Aceptar el riesgo de que los procesos de usuario 
podrían entrar en bloqueo mutuo es una cosa, pero dentro del sistema operativo mismo hay unos cuantos 
lugares en los que se ha tenido mucho cuidado de evitar problemas. El principal es la interacción entre el 
sistema de archivos y el administrador de memoria. Este último envía mensajes al sistema de archivos 
para leer el archivo binario (programa ejecutable) durante una llamada al sistema EXEC, y también en 
otros contextos. Si el sistema de archivos no está ocioso cuando el administrador de memoria intenta 
enviarle mensajes, el administrador de memoria se bloqueará. Si a continuación el sistema de archivos 
intentara enviar un mensaje al administrador de memoria, él también descubriría que la cita falló y se 
bloquearía, dando lugar a un bloqueo mutuo. 

Este problema se evitó construyendo el sistema de forma tal que el sistema de archivos nunca envía 
mensajes de solicitud al administrador de memoria, sólo respuestas, con una excepción menor. La 
excepción es que, durante el arranque, el sistema de archivos informa al administrador de memoria el 
tamaño del disco en RAM, y se garantiza que el administrador de memoria estará esperando ese mensaje. 

Es posible poner candados a dispositivos y archivos incluso sin el apoyo del sistema operativo. Un 
nombre de archivo puede servir como variable verdaderamente global, cuya presencia o ausencia puede 
ser percibida por todos los demás procesos. Al igual que en la mayor parte de los sistemas UNIX, en los 
sistemas MINIX suele estar presente un directorio especial, /usr/spool/locks/, en el que los procesos 
pueden crear archivos de candado para marcar los recursos que están utilizando. El sistema de archivos de 
MINIX también maneja los candados de advertencia para archivos al estilo posix, pero ninguno de estos 
mecanismos puede hacerse obligatorio. Todo depende del buen comportamiento de los procesos, y no hay 
nada que impida a un programa utilizar un recurso asegurado por otro proceso. Esto no es exactamente lo 
mismo que expropiar el recurso, porque tampoco impide que el primer proceso intente seguir utilizando el 
recurso. Dicho de otro modo, no hay exclusión mutua. El resultado de semejante acción por parte de un 
proceso mal comportado seguramente será un desastre, pero no habrá bloqueo mutuo. 
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3.3 DISPOSITIVOS POR BLOQUES EN MINIX 

En las siguientes secciones regresaremos a los controladores de dispositivos, el tema principal de este 
capítulo, y estudiaremos varios de ellos con detalle. MINIX maneja varios dispositivos por bloques 
distintos, así que comenzaremos por analizar los aspectos comunes de todos los dispositivos por bloques. 
Luego estudiaremos el disco en RAM, el disco duro y el disco flexible. Cada uno de éstos resulta 
interesante por una razón distinta. El disco en RAM es un buen ejemplo para estudiarlo porque tiene todas 
las propiedades de los dispositivos por bloques en general con excepción de la E/S real, ya que el “disco” 
en realidad es sólo una porción de la memoria. Esta simplificación hace que éste sea un buen lugar para 
comenzar. El disco duro ilustra en qué consiste un verdadero controlador de disco. Podríamos esperar que 
el disco flexible fuera más fácil de apoyar que el duro, pero la realidad es que no es así. No explicaremos 
todos los detalles del disco flexible, pero sí señalaremos varias de las complicaciones que se encuentran en 
su controlador. 

Después de tratar los controladores por bloques, estudiaremos otras clases de controladores. El reloj 
es importante porque todo sistema tiene uno, y porque es totalmente distinto de los demás controladores; 
además, también resulta interesante como excepción de la regla de que todos los dispositivos son por 
bloques o por caracteres, ya que no encaja en ninguna de las dos categorías. Por último, estudiaremos el 
controlador de terminal, que es importante en todos los sistemas y además es un buen ejemplo de 
controlador de dispositivo por caracteres. 

Cada una de estas secciones describe el hardware pertinente, los principios de software en que se 
basa el controlador, un bosquejo de la implementación y el código mismo. Esta estructura hace que la 
lectura de estas secciones sea de utilidad incluso para aquellos lectores a los que no les interesan los 
detalles del código mi s mo. 


3.5.1 Generalidades de los controladores de dispositivos por bloques en MINIX 

Ya mencionamos que los procedimientos principales de todas las tareas de E/S tienen una estructura 
similar. MINIX siempre tiene por lo menos tres tareas de dispositivo por bloque (el controlador del disco 
en RAM, el controlador del disco flexible y varios controladores de disco duro posibles) compiladas en el 
sistema. Además, pueden incluirse por compilación una tarea de CD-ROM y un controlador SCSI 
(interfaz estándar de computadora pequeña) si se requiere apoyo para tales dispositivos. Aunque el 
controlador de cada uno de estos dispositivos se ejecuta como proceso independiente, el hecho de que 
todos se compilan como parte del código ejecutable del kemel permite compartir una cantidad 
considerable del código, sobre todo los procedimientos de utilería. 

Desde luego, cada controlador de dispositivo por bloques tiene que hacer algo de inicialización. El 
controlador del disco en RAM debe reservar memoria, el controlador del disco duro tiene que determinar 
los parámetros del hardware del disco, etc. Todos los controladores de disco se invo can individualmente 
para la inicialización específica para el hardware, pero después de hacer lo que sea necesario, cada 
controlador invoca la función que contiene el ciclo principal común. Este ciclo se ejecuta indefinidamente; 
no hay retomo al invocador. Dentro del ciclo principal se recibe un mensaje, se invoca una fúnción que 
realice la operación requerida por cada mensaje, y se genera el mensaje de respuesta. 
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El ciclo principal común invocado por cada tarea de controlador de disco no es sólo una copia de 
una función de biblioteca compilada en cada controlador. Sólo hay una copia del código del ciclo principal 
en el binario de MINIX. La técnica que se emplea consiste en hacer que cada uno de los controladores 
individuales pase al ciclo principal un parámetro que consta de un apuntador a una tabla la cual contiene 
las direcciones de las funciones que el controlador usará para cada operación. Luego, se invocan 
indirectamente dichas funciones. Esta técnica también permite a los controladores compartir funciones. La 
Fig. 3-17 muestra un bosquejo del ciclo principal, en una forma similar a la de la Fig. 3-16. Instrucciones 
como 

code = (*entry_points_>dev_read)(&mess); 

son invocaciones indirectas de funciones. Cada controlador invoca una función dev read distinta, aunque 
todos ejecutan el mismo ciclo principal. Por otro lado, algunas otras operaciones, como CLOSE, son tan 
sencillas que más de un dispositivo puede invocar la misma función. 


message mess; /* buffer de mensajes 7 

vold sbared Jo_task($truct driver table ‘entry points) { 

/* cada tarea realiza ¡nkaalización antes de invocar esta función 7 
while(TRUE) { 

receive(ANY, &mess); 
caller - mess.source, 
switch(mess.type) { 

case READ: rcode = (*entry_points->dev_read)(&mess); break; 

case WRITE: rcode = (*entry_points-xjev_wríte)(&mess); break; 

/* Aquí van otros casos, incluidos OPEN, CLOSE e IOCTL V 
default: rcode = ERROR; 

} 

messtype = TASK_REPLY; 

mess.status = rcode; /* código de resultado */ 

send(caller, &mess); 

} 

} 

Figura 3-17. Procedimiento principal de tarea de E/S compartido usando llamadas indirectas. 


Este empleo de una sola copia del ciclo es una buena ilustración del concepto de procesos que 
presentamos en el capítulo 1 y analizamos extensamente en el capítulo 2. En la memoria sólo hay una 
copia del código ejecutable para el ciclo principal de los controladores de dispositivos por bloques, pero se 
ejecuta como ciclo principal de tres o más procesos distintos. Cada uno de estos procesos probablemente 
está en un punto distinto del código en un instante dado, y cada uno opera con su propio conjunto de datos 
y tiene su propia pila. 

Flay sE/S posibles operaciones que pueden solicitarse a cualquier controlador de dispositivo. Éstas 
corresponden a los posibles valores que se pueden encontrar en el campo m.m_type del mensaje de la Fig. 
3-15, y son: 
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1. OPEN (abrir) 

2. CLOSE (cerrar) 

3. READ (leer) 

4. WRITE (escribir) 

5. IOCTL (control de E/S) 

6. SCATTEREDIO (E/S dispersa) 


Los lectores con experiencia en programación probablemente ya conocen la mayor parte de estas 
operaciones. En el nivel de controlador de dispositivo, casi todas las operaciones están relaciona das con 
llamadas al sistema que tienen el mismo nombre. Por ejemplo, el significado de READ y WRITE debe ser 
claro. Para cada una de estas operaciones, se transfiere un bloque de datos del dispositivo a la memoria del 
proceso que inició la llamada, o viceversa. Una operación READ normalmente no causa un retomo al 
invocador antes de que se haya completado la transferencia de datos, pero un sistema operativo podría 
colocar en un buffer los datos transferidos durante un WRJTE para transferirlos realmente a su destino en 
un momento posterior, y regresar inmediata mente al invocador. Para el invocador, eso es excelente, ya 
que ahora está en libertad de reutilizar el buifer del cual el sistema operativo copió los datos que se 
escribirán. Las operaciones OPEN y CLOSE para un dispositivo tienen un significado similar al que 
tienen las llamadas al sistema OPEN y CLOSE aplicadas a operaciones con archivos: una operación 
OPEN debe verificar que el dispositivo este accesible, o devolver un mensaje de error si no lo está, y un 
CLOSE debe garan tizar que todos los datos en buffer que fueron escritos por el invocador se transfieran 
por completo a su destino final en el dispositivo. 

La operación IOCTL tal vez no sea tan conocida. Muchos dispositivos de E/S tienen parámetros 
operativos que ocasionalmente deben examinarse y tal vez modificarse. Las operaciones IOCTL se 
encargan de esto. Un ejemplo común es cambiar la rapidez de transmisión o la paridad de una línea de 
comunicación. En el caso de los dispositivos por bloques, las operaciones JOCTL son menos comunes. La 
consulta o modificación de la forma en que un dispositivo de disco está dividido en particiones se realiza 
con una operación IOCTL en MINIX (aunque podría haberse efectuado igualmente bien leyendo y 
escribiendo un bloque de datos). 

La operación SCATTERED IO sin duda es la menos conocida. Con la excepción de los dispo 
sitivos de disco excepcionalmente rápidos (por ejemplo, el disco en RAM), es difícil obtener un 
rendimiento de E/S de disco satisfactorio si todas las peticiones piden bloques individuales, uno a la vez. 
Una petición SCA 77’ERED_IO permite al sistema de archivos solicitar la lectura o escritu ra de múltiples 
bloques. En el caso de una operación READ, los bloques adicionales tal vez no hayan sido solicitados por 
el proceso a cuyo nombre se efectúa la llamada; el sistema operativo intenta anticipar 
peticiones de datos futuras. En una petición de este tipo el controlador del dispositivo 
no tiene que conceder necesariamente todas las transferencias solicitadas. La petición de 
cada bloque puede modificarse con un bit de bandera que le indica al controlador que la petición 
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es opcional. En efecto, el sistema de archivos puede decir: “sería bueno tener todos estos datos, pero 
realmente no los necesito todos en este momento”. El dispositivo puede hacer lo que más le convenga. El 
controlador del disco flexible, por ejemplo, devolverá todos los bloques de datos que pueda leer de una 
misma pista, diciendo efectivamente: “te voy a dar éstos, pero tardaría mucho en pasar a otra pista; pídeme 
el resto después”. 

Cuando es preciso escribir datos, no puede ser opcional escribir o no un bloque dado. No obstante, 
el sistema operativo puede poner en buffer varias peticiones de escritura en la suposi ción de que la 
escritura de múltiples bloques pueda efectuarse de manera más eficiente que si se atiende cada petición en 
el momento en que llega. En una petición SCA 17’ERED_IO, sea para leer o para escribir, la lista de 
bloques solicitados está ordenada, y esto hace la operación más eficiente que si se atienden las peticiones 
al azar. Además, como sólo se hace una llamada al controlador para transferir múltiples bloques, se reduce 
el número de mensajes enviados dentro de MINIX. 


3.5.2 Software controlador de dispositivos de bloques común 

Las definiciones que todos los controladores de dispositivos por bloques necesitan están en driverh. Lo 
más importante de este archivo es la estructura driver, en las líneas 9010 a 9020, que todo controlador 
utiliza para pasar una lista de las direcciones de las funciones que usará para realizar cada parte de su 
trabajo. También se define aquí la estructura device (líneas 9031 a 9034) que contiene la información más 
importante referente a las particiones, la dirección base y el tamaño en bytes. Se escogió este formato para 
que no fueran necesarias conversiones al trabajar con dispositivos basados en la memoria, maximizando 
así la rapidez de respuesta. En el caso de los discos reales hay tantos factores adicionales que retrasan el 
acceso, que la conversión a sectores no implica una tardanza significativa. 

El ciclo principal y las funciones compartidas de todas las tareas de controlador por bloques están 
en driver.c. Después de efectuar toda la inicialización específica del hardware que pudiera ser necesaria, 
cada controlador invoca driver task, pasando una estructura driver como argu mentó de la llamada. 
Después de obtener la dirección del buffer que se usará para operaciones de DMA, se entra en el ciclo 
principal (líneas 9158 a 9199). Este ciclo se ejecuta indefinidamente; no hay retomo al invocador. 

El sistema de archivos es el único proceso que se supone enviará mensajes a una tarea de 
controlador. El switch de las líneas 9165 a 9175 verifica esto. Se ignora una interrupción sobrante del 
hardware, y cualquier otro mensaje mal dirigido sólo producirá la exhibición de una adverten cia en la 
pantalla. Esto parece inocuo, pero desde luego es muy probable que el proceso que envió el mensaje 
erróneo esté bloqueado permanentemente esperando una respuesta. En el switch del ciclo principal, los 
primeros tres tipos de mensajes, DEV OPEN, DEy GLOSE y DEV IOCTL, tienen como resultado 
llamadas indirectas empleando direcciones que se pasaron en la estructura driver. Los mensajes 
DEVREAD, DEV WRITE y SCA7TERED IO producen llamadas directas a do o do vrdwt. Sin 
embargo, todas las llamadas pasan la estructura driver como argumen to desde el interior del switch, sean 
directas o indirectas, para que todas las rutinas invocadas puedan usarla también si es necesario. 
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Después de hacer lo que se solicita en el mensaje, es posible que sea necesario realizar algo de 
aseo, dependiendo de la naturaleza del dispositivo. En el caso de un disquette, por ejemplo, esto podría 
implicar iniciar un temporizador para apagar el motor de la unidad de disco si no llega pronto otra 
petición. También se usa una llamada indirecta para esto. Después del aseo, se cons huye un mensaje de 
respuesta y se envía al invocador (líneas 9194 a 9198). 

Lo primero que hace cada tarea después de entrar en el ciclo principal es invocar initbuffer (línea 
9205), que asigna un buffer para usarse en operaciones de DMA. Todas las tareas de controlador usan el 
mismo buffer, si es que acaso lo usan; algunos controladores no utilizan DMA. Las inicializaciones de 
todas las entradas después de la primera son redundantes pero no hacen daño. Sería más laborioso 
codificar una prueba para determinar si debe pasarse o no por alto la inicialización. 

Esta inicialización sólo es necesaria debido a una peculiaridad del hardware de la IBM PC original, 
que exige que el buifer de DMA no cruce una frontera de 64K. Es decir, un buffer de DMA de 1K puede 
comenzar en 64510, pero no en 64514, porque un buffer que empieza en esta última dirección se extiende 
un poco más allá de la frontera de 64K que está en 65536. 

Esta molesta regla existe porque la IBM PC usaba un chip de DMA viejo, el Intel 8237A, que 
contiene un contador de 16 bits. Se necesita un contador más grande porque el DMA usa direc ciones 
absolutas, no relativas a un registro de segmento. En las máquinas más viejas que pueden direccionar sólo 
1 M de memoria, los 16 bits de orden bajo de la dirección de DMA se cargan en el 8237A, ylos 4 bits de 
orden superior se cargan en un latch de 4 bits. Las máquinas más nuevas usan un latch de 8 bits y pueden 
direccionar 1 6M. Cuando el 823 7A pasa de OxFFFF a 0x0000, no genera un bit de acarreo que se sume 
al latch, de modo que la dirección de DMA salta repentinamente 64K hacia abajo en la memoria. 

Un programa en C portátil no puede especificar una posición de memoria absoluta para una 
esirtictura de datos, así que no hay forma de evitar que el compilador coloque el buffer en un lugar 
inadecuado. La solución es asignar memoria a un arreglo de bytes dos veces más grande que lo necesario 
en buffer (línea 9135), y reservar un apuntador tmpbuf (línea 9136) que se usará para acceder realmente 
a este arreglo, init buffer realiza un ajuste provisional de tmp buf, apuntando al principio de huffer, y 
luego prueba para determinar si deja suficiente espacio antes de llepar a una frontera de 64K. Si el ajuste 
provisional no provee suficiente espacio, se incrementa 1 bu! en el número de bytes que realmente se 
requieren. Así, siempre se desperdicia algo de espaci en liii c o en el otro del espacio asignado en buffer, 
pero nunca hay una falla debida a pie el hujier quede en una frontera de 64K. 

Las computadoras más nuevas de la familia IBM PC tienen mejores controladores en hardware para 
DM A. este código podría simplificarse, recuperándose una pequeña cantidad de memoria, ‘.i pudemos 
estar seguros de que nuestra máquina es inmune a este problema. Si usted está omsitierarido esto, piense 
cómo se manifestaría el error en caso de estar equivocado al respecto. Si Se desea un buffer de 1K para 
DMA, hay una probabilidad de 1 en 64 de que habrá un problema en una inñquina con el chip de 
DMA antiguo. Cada vez que se modifica el código fuente del kemel de modo tal que el tamaño 
del kemel compilado cambia, existe la misma probabilidad de que se manifieste el 
problema. Lo más probable es que el siguiente mes o el siguiente año, cuando ocurra la 
falla, se atribuya al último código que se modificó. Características inesperadas del hardware 
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como ésta pueden hacer que desperdiciemos semanas buscando errores extraordinariamente difíciles de 
rastrear (sobre todo cuando, como en este caso, el manual de referencia técnica no dice ni una palabra al 
respecto). 

La siguiente función de driver c es dordwt. Ésta, a su vez, puede invocar tres funciones 
dependientes del dispositivo a las que apuntan los campos dr_prepare, drschedule y drfinish. En lo que 
sigue usaremos la flotación del lenguaje C * apuntador a función para indicar que estamos hablando de la 
función a la que apunta apuntador a función. 

Después de verificar que la cuenta de bytes en la petición sea positiva, do rdwt invoca a *dr 
prepare. Ésta debe tener éxito, ya que *dr prepare sólo puede fallar si se especifica un dispositivo no 
válido en una operación OPEN. A continuación se llena una estructura iorequests estándar (definida en la 
línea 3194 en include/minixllype.h). Luego viene otra llamada indirecta, esta vez a *drschedule Como 
veremos cuando hablemos del hardware de disco en la siguiente sección, responder a las peticiones de 
disco en el orden en que se reciben puede ser poco eficiente, y esta rutina permite a un dispositivo en 
particular manejar las peticiones en la forma que resulte óptima para el dispositivo. La indirección en este 
caso enmascara gran parte de las posibles varia ciones en la forma como funcionan los dispositivos 
individuales. En el caso del disco en RAM, dr schedule apunta a una rutina que realmente realiza la BIS, 
y la siguiente llamada indirecta, a *drfjnjsh, es una operación que no hace nada. En el caso de un disco 
real, dr finish apunta a una rutina que lleva a cabo todas las transferencias de datos pendientes solicitadas 
en todas las llama das anteriores a *dr schedule después de la última llamada a *dr finish. Sin embargo, 
como veremos, en algunas circunstancias la llamada a *dr finish podría no lograr la transferencia de todos 
los datos solicitados. 

En cualquier llamada que sea la que realice una transferencia real de datos, se modifica el contador 
io n bytes de la estructura iorequest s, devolviendo un número negativo si hubo un error o uno positivo 
para indicar la diferencia entre el número de bytes especificados en la petición original y los bytes que se 
transfirieron con éxito. No es necesariamente un error que no se haya transferido ningún byte; esto indica 
que se llegó al final del dispositivo. Al regresar al ciclo prin cipal, el código de error negativo se devuelve 
en el campo REPSTATUS del mensaje de respuesta si hubo un error. Si no, los bytes que faltan por 
transferirse se restan de la petición original en el campo COUNT del mensaje (línea 9249) y el resultado 
(el número realmente transferido) se devuelve en REP STATUS en el mensaje de respuesta de 
drivertask. 

La siguiente función, do vrdwt, maneja todas las peticiones de E/S dispersa. Un mensaje 
que solicita E/S dispersa utiliza el campo ADDRESS para apuntar a un arreglo de 
estructuras tipo iorequest s, cada una de las cuales especifica la información que se necesita 
para una petición: la dirección del buffer, el desplazamiento dentro del dispositivo, el número 
de bytes y si se va a leer o a escribir. Las operaciones de una petición deben ser todas de lectura 
o todas de escritura, y estar ordenadas en orden de bloque dentro del dispositivo. Se debe trabajar 
más que en la lectura o escritura sencilla realizada con do rdwt, ya que el arreglo de 
peticiones debe copiarse en el espacio de kemel, pero una vez que se ha hecho esto se efectúan 
las mismas tres llamadas indirectas a las rutinas dependientes del dispositivo *dr prepare, *dr schedule 
y *dr finish La diferencia es que la llamada de en medio, *dr schedule, se ejeduta en un ciclo, una vez 
para cada petición, o hasta que ocurre un error (líneas 9288 a 9290). Una vez finalizado el ciclo, se invoca 
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una vez *dr ñn ish, y luego se vuelve a copiar el arreglo de peticiones en el lugar de donde se obtuvo. El 
campo io nbytes de cada elemento del arreglo se habrá modificado de modo que refleje el número de 
bytes transferidos, y aunque el total no se regresa directamente en el mensaje de respuesta que drivertask 
construye, el invocador puede extraer el total de este arreglo. 

En una petición de lectura de E/S dispersa, no todas las transferencias solicitadas en la llamada a 
*dr_schedule se habrán efectuado forzosamente cuando se efectúe la llamada final a *drfinish, como 
explicamos en la sección anterior. El campo io request de la estructura iorequest s contiene un bit de 
bandera que le indica al controlador de dispositivo si la petición de ese bloque es opcional. 

Las siguientes rutinas de drive proporcionan apoyo general a las operaciones anteriores. Se puede 
usar una llamada a *dr ñame para obtener el nombre de un dispositivo. Si el dispositivo no tiene un 
nombre específico, la función noname obtiene el nombre del dispositivo de la tabla de tareas, Algunos 
dispositivos podrían no requerir un servicio en particular; por ejemplo, un disco en RAM no requiere que 
se haga nada especial para atender una petición DEV CLOSE (cerrar dispositivo). En este caso la función 
do nop atiende la petición, devolviendo diversos códigos en función del tipo de petición. Las rutinas que 
siguen, nop finish y nop cleanup, son rutinas ficticias similares para dispositivos que no requieren los 
servicios de *dr finish ni de *dr_cleanup. 

Algunas funciones de dispositivos de disco requieren retrasos; por ejemplo, para esperar que el 
motor de una unidad de disquete alcance la velocidad de operación. Por ello, driver.c es un buen lugar 
para la siguiente función, clockmess, que sirve para enviar mensajes a la tarea del reloj. Esta función se 
invoca con el número de tics de reloj que hay que esperar y la dirección de la función que debe invocarse 
cuando haya transcurrido el plazo. 

Por último, dodiocntl (línea 9364) lleva a cabo peticiones DEV IOCTL para un dispositivo por 
bloques. Es un error solicitar cualquier operación de DEV JOCTL que no sea leer (DIOGETP) o escribir 
(DJOSETP) información de particiones. Do diocntl invoca la función *dr_ prepare del dispositivo para 
verificar que el dispositivo sea válido y obtener un apuntador a la estructura device que describe la base y 
el tamaño de las particiones en bytes. En una petición de lectura, do diocntl invoca la función 
*dr_geometry para obtener la información de cilindro, cabeza y sector de la partición. 


3.5.3 La biblioteca de controladores 

Los archivos drvlib.h y drvlib.c contienen código dependiente del sistema que maneja las partí ciones de 
disco en computadoras compatibles con IBM PC. 

Las particiones permiten dividir un solo dispositivo de almacenamiento en subdispositivos. Las 
particiones se usan comúnmente en los discos duros, pero MINIX también proporciona apoyo para la 
división en particiones de los discos flexibles. Entre las razones para dividir un disco en particiones 
podemos citar: 

1. La capacidad de disco es más económica por unidad en los discos grandes. 
Si se usan dos o más sistemas operativos con diferentes sistemas de archivos, resulta más 
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económico dividir en particiones un solo disco grande que instalar varios discos de menor tamaño, uno 
para cada sistema operativo. 

2. Los sistemas operativos pueden tener límites en cuanto al tamaño de dispositivos que pueden 
manejar. La versión de MINIX que estudiamos aquí puede manejar un sistema de archivos de 1 GB, pero 
las versiones antiguas están limitadas a 256 MB. Todo el espacio de disco adicional se desperdicia. 

3. Un sistema operativo podría usar dos o más sistemas de archivos distintos. Por ejemplo, podría 
usarse un sistema de archivos estándar para los archivos ordinarios y uno con una estructura diferente para 
el espacio de intercambio de la memoria virtual. 

4. Puede ser aconsejable colocar una porción de los archivos de un sistema en un dispositivo lógico 
independiente. Si se coloca el sistema de archivos raíz de MINIX en un dispositivo pequeño será fácil 
respaldarlo y copiarlo en un disco en RAM en el momento del arranque. 


El manejo de las particiones de disco es específico para cada plataforma. La especificidad no tiene 
que ver con el hardware, pues el apoyo de particiones es independiente del dispositivo. Sin embargo, si 
desea ejecutarse más de un sistema operativo en un conjunto de hardware dado, todos deben acordar un 
formato para la tabla de particiones. En las IBM PC el estándar lo estable ce el comando fdisk de MS- 
DOS, y otros sistemas operativos, como MINIX, OS/2 y Linux, usan este formato para poder coexistir con 
MS-DOS. Si se traslada MINIX a otro tipo de máquina, tiene sentido usar un formato de tabla de 
particiones compatible con otros sistemas operativos instala dos en el nuevo hardware. Es por ello que el 
código fuente de MINIX que apoya las particiones en computadoras IBM se coloca en drvlib.c, en lugar 
de incluirse en driver.c; eso facilita el traslado de MINIX a hardware distinto. 

La estructura de datos básica heredada de los diseñadores de firmware se define en includel 
ihm/partition.h, que se incluye mediante una instrucción #include en drvlib.h. Dicha estructura contiene 
información sobre la geometría cilindro-cabeza-sector de cada partición, así como códi gos que identifican 
el tipo de sistema de archivos de la partición y una bandera activa que indica si es arrancable. MINIX no 
necesita casi nada de esta información una vez que se verifica el sistema de archivos. 

La función partition (en drvlib.c, línea 9521) se invoca cuando se abre por primera vez un 
dispositivo por bloques. Sus argumentos incluyen una estructura driver, para que pueda invocar funciones 
específicas del dispositivo, un número de dispositivo secundario inicial y un parámetro que indica si el 
estilo de partición es disco flexible, partición primaria o subpartición. Partition invoca la función *dr_ 
prepare específica para el dispositivo a fin de verificar que el dispositivo sea válido y 
colocar la dirección base y el tamaño en una estructura device del tipo mencionado en la sección 
anterior. Luego partition invoca get_part_table para determinar si está presente una tabla 

de particiones y, en caso dado, leerla. Si no hay tabla de particiones, la función habrá 
terminado su trabajo; si la hay, se calculará el número de dispositivo secundario de la primera 
partición usando las reglas de numeración de dispositivos secundarios que apliquen al estilo de partición 
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especificado en la llamada original. En el caso de particiones primarias, la tabla de particiones está 
ordenada de modo que el orden de las particiones sea congruente con el que usan otros sistemas 
operativos. 

En este punto se invoca otra vez *dr prepare, esta vez usando el número de dispositivo i calculado 
para la primera partición. Si el subdispositivo es válido, se procesarán cíclicamente todas las entradas de la 
tabla, comprobando que los valores leídos de la tabla en el dispositivo no estén fuera del intervalo 
calculado antes para la base y el tamaño de todo el dispositivo. Si hay una discrepancia, la tabla en 
memoria se ajusta de modo que sea congruente. Esto puede parecer paranoico, pero dado que las tablas de 
particiones pueden haber sido escritas por diferentes sistemas operativos, un programador, usando otro 
sistema, puede haber tratado de usar ingenio sámente la tabla de particiones para algo inesperado, o podría 
haber basura en la tabla en disco por alguna otra razón. Confiamos más en los números que calculamos 
usando MINIX. Más vale asegurarse que tener que arrepentirse. 

Aún dentro del ciclo, para todas las particiones del dispositivo, si la partición se identifica como una 
partición MINIX, se invoca partition recursivamente a fin de obtener información sobre las subparticiones. 
Si la partición se identifica como una partición extendida, se invoca más bien la siguiente fúnción del 
archivo, extpartition. 

Extpartition (línea 9593) realmente no tiene nada que ver con el sistema operativo MINIX, así que 
no la explicaremos con detalle, MS-DOS usa particiones extendidas, que no son sino un meca nismo más 
para crear subparticiones. Si queremos apoyar los comandos de MINIX capaces de leer y escribir archivos 
MS-DOS, necesitamos tener conocimiento de estas subparticiones. 

Get_part_table (línea 9642) invoca do rdwt para obtener el sector de un dispositivo (o 
subdispositivo) donde se encuentra una tabla de particiones. El desplazamiento que se incluye como 
argumento es cero si la invocación es para obtener una partición primaria, y distinto de cero en el caso de 
una subpartición. La fúnción busca el número mágico (OxAA55) y devuelve un estado verdadero o falso 
para indicar si se encontró o no una tabla de particiones válida. Si se encuentra la tabla, se copia en la 
dirección de tabla que se pasó como argumento. 

Por último, sort (línea 9676) ordena las entradas de una tabla de particiones en orden aseen dente 
por sector. Las entradas marcadas como carentes de particiones se excluyen del ordenamiento, quedando 
al final aunque tengan un valor de cero en su campo de sector bajo. El ordenamiento es del tipo de 
burbuja; no hay necesidad de usar un algoritmo elegante para ordenar una lista de cuatro elementos. 


3,6 DISCOS EN RAM 

Ahora regresaremos a los controladores de dispositivos por bloques individuales y estudiaremos varios de 
ellos detalladamente. El primero que veremos es el controlador de disco en RAM, que puede proporcionar 
acceso a cualquier parte de la memoria. La aplicación principal de este controlador es reservar una parte 
de la memoria para ser usada como disco ordinario. Esto no quiere decir que el almacenamiento sea 
permanente, pero una vez que los archivos se copian en esta área el acceso a ellos puede ser 
extremadamente rápido. 
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En un sistema como MINIX, que se diseñó para funcionar en computadoras que apenas contaban 
con un disco flexible, el disco en RAM tiene otra ventaja. Si colocamos el dispositivo raíz en el disco en 
RAM, el solitario disco flexible puede montarse y desmontarse a voluntad, manejando así medios 
removibles. Si se colocara el dispositivo raíz en el disco flexible sería imposible guar dar archivos en 
disquete, ya que el dispositivo raíz (el único disquete) no puede desmontarse. Ade más, tener el 
dispositivo raíz en el disco en RAM hace al sistema muy flexible; se puede montar en él cualquier 
combinación de discos flexibles o duros. Aunque la mayor parte de las computadoras ahora tienen disco 
duro, con excepción de las utilizadas en sistemas incorporados, el disco en RAM es útil durante la 
instalación, antes de que el disco duro esté listo para ser utilizado por MINIX, o cuando se desea usar 
MINLX temporalmente sin realizar una instalación completa. 


3.6.1 Hardware y software de discos en RAM 

La idea en que se basa el disco en RAM es sencilla. Un dispositivo por bloques es un medio de 
almacenamiento con dos comandos: escribir un bloque y leer un bloque. Normalmente, estos bloques se 
guardan en memorias giratorias, como discos flexibles o discos duros. Un disco en RAM es más sencillo: 
simplemente usa una porción preasignada de la memoria principal para almacenar los bloques. El disco en 
RAM tiene la ventaja de ofrecer acceso instantáneo (no hay búsqueda ni retraso rotacional), lo que lo hace 
adecuado para almacenar programas o datos a los que se accede con frecuencia. 

Como acotación, vale la pena señalar brevemente una diferencia entre los sistemas que mane jan 
sistemas de archivos montados y los que no lo hacen (como MS-DOS y WINDOWS). En los sistemas de 
archivos montados, el dispositivo raíz siempre está presente y en un lugar fijo, y es posible montar 
sistemas de archivos removibles (esto es, discos) en el árbol de archivos para formar un sistema de 
archivos integrado. Una vez que todo está montado, el usuario no tiene que preocuparse por saber en qué 
dispositivo está un archivo. 

En contraste, en los sistemas como MS-DOS el usuario debe especificar la ubicación de cada 
archivo, ya sea explícitamente como en B:\DIR\ARCHIVO o usando ciertos valores predetermi nados 
(dispositivo actual, directorio actual, etc.). Si sólo hay uno o dos discos flexibles, esta carga es manejable, 
pero en los sistemas de cómputo grandes, con docenas de discos, tener que seguir la pista continuamente a 
todos los dispositivos sería insoportable. Recuerde que UNIX se ejecuta en sistemas que van desde una 
IBM PC o una estación de trabajo hasta supercomputadoras como la Cray-2; MS-DOS sólo se ejecuta en 
sistemas pequeños. 

En la Fig. 3-18 se ilustran los fúndamentos del disco en RAM. Este disco se divide en n bloques, 
dependiendo de cuánta memoria se le haya asignado. Cada bloque tiene el mismo tamaño que los bloques 
empleados en los discos reales. Cuando el controlador recibe un mensaje indicán dolé que lea o escriba un 
disco, simplemente calcula el lugar dentro de la memoria del disco en RAM en el que está el bloque 
solicitado y lo lee o escribe, en lugar de hacerlo en un disco flexible o duro. La transferencia se efectúa 
invocando un procedimiento en lenguaje ensamblador que copia de o hacia el programa de usuario con la 
máxima rapidez de que el sistema es capaz. 
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Figura 3-18. Un disco en RAM. 


Un controlador de disco en RAM puede manejar varias áreas de memoria utilizadas como discos 
en RAM, cada una distinguida mediante un número de dispositivo secundario. Por lo regular estas áreas 
no se traslapan, pero en algunas situaciones puede resultar conveniente hacer que se traslapen, como 
veremos en la siguiente sección. 


3.6.2 Generalidades del controlador de disco en RAM en MINIX 

El controlador de disco en RAM es en realidad cuatro controladores en uno, todos muy relacionados entre 
sí. Cada mensaje que envía al controlador especifica un dispositivo secundario como sigue: O: ¡dey/ram 1: 
/dev/mem 2: /devlkmem 3:/dev/null 

El primero de estos archivos especiales, ¡dey/ram, es un verdadero disco en RAM. Ni su tamaño ni 
su origen están incorporados en el controlador; estas características las determina el sistema de archivos 
cuando se arranca MINIX. Por omisión, se crea un disco en RAM con el mismo tamaño que el dispositivo 
imagen del sistema de archivos raíz, a fin de poder copiar en él dicho sistema de archivos. Se puede usar 
un parámetro de arranque para especificar un disco en RAM más grande que el sistema de archivos raíz o, 
si no se va a copiar en RAM la raíz, se puede especificar cualquier tamaño que quepa en la memoria y que 
deje suficiente memoria para el funciona mi ento del sistema. Una vez determinado el tamaño, se localiza 
un bloque de memoria suficientemente grande y se retira de la reserva de memoria aun antes de que el 
administrador de memoria inicie su trabajo. Tal estrategia permite aumentar o reducir el tamaño del disco 
en RAM sin tener que recompilar el sistema operativo. 

Los dos dispositivos secundarios siguientes se utilizan para leer y escribir memoria 
física y memoria del kemel, respectivamente. Cuando se abre y lee /dev/mem, se obtiene el contenido de 
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las posiciones de memoria física comenzando por la dirección de memoria absoluta cero (los vectores de 
interrupción en modo real). Los programas de usuario ordinarios nunca hacen esto, pero un programa de 
sistema que se ocupa de depurar el sistema podría necesitar este recurso. Si se abre /dev/mem y se escribe 
en él se modifican los vectores de interrupción. Huelga decir que esto sólo debe efectuarlo un usuario 
experimentado que sepa exactamente lo que está haciendo, y procediendo con la mayor cautela. 

El archivo especial /dev/kmem es parecido a /dev/mem, excepto que el byte O de este archivo es el 
byte O de la memoria de datos del kemel. La dirección absoluta de esta posición varía dependiendo del 
tamaño del código del kemel de MINIX. Esta posición también se usa principalmente para depuración y 
programas muy especiales. Observe que las áreas de disco en RAM cubiertas por estos dos dispositivos 
secundarios se traslapan. Si sabemos exactamente cómo está ubicado el kemel en la memoria, podemos 
colocamos en el principio del área de datos del kemel y ver exactamente lo mismo que obtenemos cuando 
leemos desde el principio de Idev/kmem. Sin embargo, si recompilamos el kemel cambiando su tamaño, o 
si en versiones subsecuentes de MINIX el kemel se coloca en algún otro lugar de la memoria, tendremos 
que colocamos en un lugar diferente de /dev/mem para ver lo mismo que vemos al principio de 
/dev/kmem. Estos dos archivos especiales deben protegerse para evitar que nadie que no sea el 
superusuario los utilice. 

El último archivo de este grupo, /dev/null, es un archivo especial que acepta datos y los desecha. 
Este archivo se utiliza comúnmente en comandos del shell, cuando el programa invoca do genera salidas 
que no sirven de nada. Por ejemplo, 

a.out >/dev/nuIl 

ejecuta el programa a.out pero desecha sus salidas. El controlador de disco en RAM efectivamen te trata 
este dispositivo secundario como si tuviera tamaño cero, así que jamás se copian datos en él ni de él. 

El código para manejar /dey/ram, /dev/mem y /dev/kmem es idéntico. La única diferencia entre ellos 
es que cada uno corresponde a una porción diferente de la memoria, indicada por los arreglos ram origin 
y ramlimit, cada uno indizado por un número de dispositivo secundario. 


3.6.3 Implementación del controlador de disco en RAM en MINIX 

Al igual que en otros controladores de disco, el ciclo principal del controlador de disco en RAM 
está en el archivo drive,x. El apoyo específico para dispositivos de memoria está en memory.c. El arreglo 
mgeom (línea 9721) contiene la base y el tamaño de cada uno de los cuatro dispositivos de memoria. La 
estructura driver de mdtab en las líneas 9733 a 9743 define las llamadas de dispositivo de memoria que 
se harán desde el ciclo principal. Cuatro 1 1 entradas de esta tabla son rutinas que hacen nada o casi nada 
en driver.c, indicio seguro de que el fúncionamiento de un disco en RAM no es muy complicado que 
digamos. El procedimiento principal memtask (línea 9749) invoca una fúnción que realiza algunas 
inicializaciones locales, y a continuación invoca el ciclo principal, el cual recibe mensajes, ejecuta el 
procedimiento apropiado y devuelve respuestas. No hay retomo a nzemtask una vez completado este 
ciclo. 
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En una operación de lectura o escritura, el ciclo principal efectúa tres llamadas: una para preparar 
un dispositivo, una para planificar las operaciones de E/S y una para terminar la operación. En el caso de 
los dispositivos de memoria, la primera de estas llamadas se hace a m_prepare. Esta función comprueba 
que se haya solicitado un dispositivo secundario válido y luego devuelve la direc ción de la estructura que 
contiene la dirección base y el tamaño del área de RAM solicitada. La segunda llamada es a mschedule 
(línea 9774), que es la función que realiza todo el trabajo. En el caso de los dispositivos de memoria el 
nombre de esta función es poco apropiado; por definición, en la memoria de acceso aleatorio (RAM) 
cualquier posición es tan accesible como cualquier otra, así que no hay necesidad de planificar, como sería 
el caso en un disco provisto de un brazo móvil. 

El funciona mi ento del disco en RAM es tan sencillo y rápido que nunca hay necesidad de posponer 
una petición, así que lo primero que hace esta función es poner en O el bit que podría ser puesto en 1 por 
una llamada de E/S dispersa para indicar que la terminación de una operación es opcional. La dirección de 
destino que se pasa en el mensaje apunta a una posición dentro del espacio de memoria del invocador, y el 
código de las líneas 9792 a 9794 convierte esta posición en una dirección absoluta en la memoria del 
sistema, comprobando después que se trata de una dirección válida. La transferencia de datos propiamente 
dicha se efectúa en la línea 9818 o en la 9820 y es un copiado directo de datos de un lugar a otro. 

Los dispositivos de memoria no necesitan un tercer paso para ter mi nar una operación de lectura o 
escritura, y la ranura correspondiente de mdtab es una llamada a nop finish. 

La apertura de un dispositivo de memoria se hace con mdoopen (línea 9829). La acción principal 
se efectúa invocando m_prepare para verificar que se esté haciendo referencia a un dispositivo válido. En 
el caso de una referencia a /dev/mem o a /devlkmem, se hace una llamada a enableiop (en el archivo 
protect.c) para cambiar el nivel de privilegio actual de la CPU. Esto no es necesario para acceder a la 
memoria; es un truco para resolver otro problema. Recuerde que las CPU Pentium implementan cuatro 
niveles de privilegio. Los programas de usuario son el nivel menos privilegiado. Los procesadores Intel 
también tienen una característica arquitectónica que no está presente en muchos otros sistemas: un 
conjunto de instrucciones independiente para direccionar los puertos de E/S. En estos procesadores, los 
puertos de E/S se tratan aparte de la memoria, Normalmente, cuando un proceso de usuario intenta 
ejecutar una instrucción que direcciona un puerto de E/S, se produce una excepción de protección general. 
Por otro lado, hay razones válidas para que MINIX permita a los usuarios escribir programas capaces de 
acceder a los puertos, sobre todo en los sistemas pequeños. Por tanto, enable iop cambia los bits de nivel 
de protección de E/S (IOPL) de la CPU a fin de permitir esto. El efecto es que un proceso que tiene 
permiso de abrir /dev/mem o/dev/kmem cuenta también con el privilegio adicional de acceso a los puertos 
de E/S. En una arquitectura en la que los dispositivos de E/S se direccionan como posiciones de memoria, 
los bits rwx de estos dispositivos cubren automáticamente el acceso a E/S. Si esta capacidad estuviera 
oculta, podría considerarse como un defecto de seguridad, pero ahora usted está enterado de ella. Si usted 
planea usar MINIX para controlar el sistema de seguridad de un banco, tal vez prefiera recompilar MINIX 
excluyendo esta función. 

La siguiente función, minit (línea 9849), sólo se invoca una vez, cuando se llama 
inicialmente memtus’k. Esta fúnción establece la dirección base y el tamaño de /dev/kmem y 
también establece el tamaño de Idevlmem en 1 MB, 16 MB o 4 GB—1, dependiendo de si MINIX se está 
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ejecutando en modo 8088, 80286 u 80386. Estos tamaños son los máximos que MINIX maneja y nada 
tienen que ver con la cantidad de RAM instalada en la máquina. 

El disco en RAM apoya varias operaciones de IOCTL en mjoctl (línea 9874). MIO CRAMSIZE es 
un mecanismo cómodo para que el sistema de archivos fije el tamaño del disco en RAM. La operación 
MIOCSPSINFO es utilizada tanto por el sistema de archivos como por el administra dor de memoria para 
establecer las direcciones de sus partes de la tabla de procesos en la tabla psinfo, de donde el programa de 
utilería ps puede obtenerla usando una operación MIOCGPSINFO. Ps es un programa UNIX estándar 
cuya implementación se complica por la estructura de microkemel de MINIX, que coloca la información 
de tabla de procesos que el programa necesita en varios lugares distintos. La llamada al sistema IOCTL es 
una forma cómoda de resolver este problema. De lo contrario, habría que compilar una versión nueva de 
ps cada vez que se compilara una nueva versión de MINIX. 

La última función de memory.c es mgeometly (línea 9934). Los dispositivos de memoria no tienen 
una geometría de cilindros, pistas y sectores como las unidades de disco mecánicas, pero en caso de que se 
le pregunte al disco en RAM, éste simulará que la tiene. 


3.7 DISCOS 

El disco en RAM es una buena introducción a los controladores de disco (por ser tan sencillo), pero los 
discos reales tienen varios aspectos que aún no hemos tratado. En las siguientes secciones hablaremos un 
poco del hardware de disco y luego examinaremos los controladores de disco en general y el controlador 
de disco duro de MINIX en particular. No estudiaremos con detalle el controlador del disco flexible, pero 
sí mencionaremos algunas de las diferencias entre los con troladores de disco duro y los de disco flexible. 


3.7.1 Hardware de discos 

Todos los discos reales están organizados en cilindros, cada uno de los cuales contiene tantas pistas como 
cabezas hay apiladas verticalmente. Las pistas se dividen en sectores, de los cuales por lo regular hay entre 
8 y 32 por pista en los discos flexibles, llegando a varios cientos en algunos discos duros. Los diseños más 
sencillos tienen el mismo número de sectores en todas las pistas. Todos los sectores tienen el mismo 
número de bytes, aunque si pensamos un poco nos daremos cuenta de que los sectores cercanos al borde 
exterior del disco son físicamente más largos que los cercanos al centro. No obstante, el tiempo que toma 
leer o escribir un sector es el mismo. La densidad de los datos obviamente es más alta en los cilindros más 
interiores, y algunos diseños de disco requieren modificar la corriente de alimentación a las cabezas de 
lectura-escritu ra para las pistas interiores. El controlador en hardware del disco se encarga de esto sin que 
lo vea el usuario (o el implementador del sistema operativo). 

La diferencia en la densidad de los datos entre las pistas interiores y exteriores implica un 
sacrificio de la capacidad, y existen sistemas más complejos. Se han probado diseños 
de disco flexible que giran con mayor rapidez cuando las cabezas están sobre las pistas exteriores. Esto 



SEC. 3.7 


DISCOS 


201 


permite tener más sectores en esas pistas, incrementando la capacidad del disco. Sin embargo, ningún 
sistema para el cual MINIX actualmente está disponible reconoce tales discos. Los discos duros modernos 
de gran capacidad también tienen más sectores por pista en las pistas exteriores que en las interiores. Éstas 
son las unidades IDE (Integrated Drive Electronics), y el complejo procesamiento que los circuitos 
incorporados en la unidad realizan enmascara los detalles. Para el sistema operativo, estas unidades 
aparentan tener una geometría sencilla con un número constan te de sectores por pista. 

Los circuitos de la unidad y del controlador en hardware son tan importantes como el equipo 
mecánico. El principal elemento de la tarjeta controladora que se instala en el plano posterior de la 
computadora es un circuito integrado especializado, en realidad una microcomputadora pequeña. En el 
caso de un disco duro puede ser que los circuitos de la tarjeta controladora sean más sencillos que para un 
disco flexible, pero esto es así porque la unidad de disco duro en sí tiene un potente controlador 
electrónico incorporado. Una característica del dispositivo que tiene implicaciones importantes para el 
controlador del disco en software es la posibilidad de que el controlador en hardware realice búsquedas de 
sectores en dos o más unidades al mismo tiempo. Esto se conoce como búsquedas traslapadas. Mientras el 
controlador en hardware y en soft ware están esperando que se lleve a cabo una búsqueda en una unidad, 
el controlador en hardware puede iniciar una búsqueda en otra unidad. También, muchos controladores en 
hardware pueden leer o escribir en una unidad mientras buscan en otra u otras, pero un controlador de 
disco flexible no puede leer o escribir en dos unidades al mismo tiempo. (La lectura o escritura requiere 
que el controlador transfiera bits en una escala de tiempo de microsegundos, por lo que una transferencia 
ocupa casi toda su potencia de cómputo.) La situación es diferente en el caso de los discos duros con 
controladores integrados en hardware, y en un sistema provisto de más de uno de estos discos duros los 
controladores pueden operar simultáneamente, al menos hasta el grado de transferir datos entre el disco y 
la memoria intermedia del controlador. Sin embargo, sólo es posible una transferencia a la vez entre el 
controlador y la memoria del sistema. La capacidad para realizar dos o más operaciones al mismo tiempo 
puede reducir considerablemente el tiempo de acceso medio. 

En la Fig. 3-19 se comparan los parámetros de disquetes de doble lado y doble densidad, que eran 
el medio de almacenamiento estándar de la IBM PC original, y los parámetros de un disco duro de 
mediana capacidad como el que podría encontrarse en una computadora basada en Pentium MINIX usa 
bloques de 1K, así que con cualquiera de estos dos formatos de disco los bloques que el software usa 
consisten en dos sectores consecutivos, que siempre se leen o escriben juntos como una unidad. 

Algo que debemos tener presente al estudiar las especificaciones de los discos duros moder nos es 
que la geometría especificada y utilizada por el controlador en software puede diferir del formato físico, 
EJ disco duro descrito en la Fig. 3-19, por ejemplo, se especifica con “parámetros 
de configuración recomendados” de 1048 cilindros, 16 cabezas y 63 sectores por pista. Los 
circuitos del controlador montados en el disco convierten los parámetros de cabeza y sector lógicos 
proporcionados por el sistema operativo en los parámetros físicos empleados por el disco. Éste 
es otro ejemplo de un arreglo diseñado para mantener la compatibilidad con sistemas más 
antiguos, en este caso firmware viejo. Los diseñadores de la IBM PC original sólo apartaron 
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Parámetro 

Disquete IBM de 360 KB 

Disco duro WD de 540 MB 

Número de cilindros 

40 

1048 

Pistas por cilindro 

2 

' ' ~ l 

Sectores por pista 

9 

252 

Sectores por dieco 

720 

1056384 

Bytes por sector 

512 

512 

Bytes por disco 

368640 

540868608 

Tiempo de búsqueda (cilindros adyacentes) 

6 ms 

4 ms 

Tiempo de búsqueda (caso medio) 

77 ms 

11 ms 

Tiempo de rotación 

200 ms 

13 ms 

Tiempo de arranque/paro del motor 

250 ms 

9 s ' 

Tiempo para transferir un sector 

22 ms 

53 ms 1 


Figura 3-19. Parámetros de disco para el disquete de 360 KB de la IBM PC original y un 
disco duro Western Digital WD AC2540 de 540 MB. 


un campo de 6 bits para contar sectores en el ROM de BIOS, y un disco que tiene más de 63 sectores por 
pista debe trabajar con un conjunto artificial de parámetros de disco lógicos. En este caso las 
especificaciones del proveedor dicen que en realidad hay cuatro cabezas, y por tanto podría parecer que 
realmente hay 252 sectores por pista, como se indica en la figura. Ésta es una simplificación, porque los 
discos de este tipo tienen más sectores en las pistas exteriores que en las interiores. El disco descrito en la 
figura sí tiene cuatro cabezas físicas, pero en realidad hay un poco más de 3000 cilindros. Los cilindros se 
agrupan en una docena de zonas que tienen desde 57 sectores por pista en las zonas más interiores hasta 
105 cilindros por pista en los cilindros más exteriores. Estos números no se encuentran en las 
especificaciones del disco, y las traducciones realizadas por los circuitos electrónicos de la unidad nos 
ahorran tener que conocer tales detalles. 


3.7.2 Software de discos 

En esta sección veremos algunos aspectos relacionados con los controladores de disco en general. 
Primero, considere cuánto tiempo toma leer o escribir un bloque de disco. El tiempo requerido está 
determinado por tres factores: 

1. El tiempo de búsqueda (el tiempo que toma mover el brazo al cilindro correcto). 

2. El retraso rotacional (el tiempo que tarda el sector correcto en girar hasta quedar bajo la cabeza). 

3. El tiempo real de transferencia de datos. 

En casi todos los discos, el tiempo de búsqueda es mucho mayor que los otros dos, así que si reducimos el 
tiempo de búsqueda mejoraremos sustancialmente el rendimiento del sistema. 
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Los dispositivos de disco son propensos a errores. Siempre se graba junto con los datos de cada 
sector de un disco algún tipo de verificación de errores, una suma de verificación o una verificación de 
redundancia cíclica. Incluso las direcciones registradas cuando se formatea un disco cuentan con datos de 
verificación. El controlador en hardware de un disco flexible puede informar cuando se detecta un error, 
pero el software debe decidir qué se hará al respecto. Los controladores en hardware de los discos duros 
con frecuencia asumen gran parte de esta carga. Sobre todo en el caso de los discos duros, el tiempo de 
transferencia de sectores consecutivos dentro de la misma pista puede ser muy rápido. Por ello, la lectura 
de más datos de los que se solicitan y su almacenamiento en un caché de la memoria puede ser una 
estrategia muy eficaz para acelerar el acceso a disco. 


Algoritmos de planificación del brazo del disco 

Si el controlador en software del disco acepta peticiones una por una y las atiende en ese orden, es decir, 
el primero que llega, el primero que se atiende (FCFS: first come, first served), poco puede hacerse por 
optimar el tiempo de búsqueda. Sin embargo, cuando el disco está sometido a una carga pesada puede 
usarse otra estrategia. Es probable que, mientras el brazo está realizando una búsqueda para atender una 
petición, otros procesos generen otras peticiones de disco. Muchos controladores de disco mantienen una 
tabla, indizada por número de cilindro, con todas las peticiones pendientes para cada cilindro encadenadas 
en listas enlazadas cuyas cabezas son las entradas de la tabla. 

Dado este tipo de estructura de datos, podemos utilizar un mejor algoritmo que el del primero que 
llega, primero que se atiende. Para entender este algoritmo, consideremos un disco de 40 cilindros. Llega 
una petición para leer un bloque que está en el cilindro 11. Mientras se está realizando la búsqueda del 
cilindro 11, llegan peticiones nuevas para los cilindros 1, 36, 16, 34, 9 y 12, en ese orden, y se introducen 
en la tabla de peticiones pendientes, con una lista enlazada individual para cada cilindro. Las peticiones se 
muestran en la Fig. 3-20. 



Figura 3-20. Algoritmo de planificación de la primera búsqueda más corta (SSF). 


Cuando se termina de atender la petición en curso (para el cilindro 11), el controlador de disco 
puede escoger la petición que atenderá a continuación. Si el controlador usara FCFS, iría después al 
cilindro 1, luego al 36, y así sucesivamente. Este algoritmo requeriría movi mi entos del brazo de 10, 35, 
20, 18, 25 y 3, respectivamente, para un total de 111 cilindros. 
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Como alternativa, el controlador podría atender a continuación la petición más cercana, a fin de 
minimizar el tiempo de búsqueda. Dadas las peticiones de la Fig. 3-20, la secuencia es 12, 9, 16, 1, 34 y 
36, como indica la línea punteada en la parte inferior de la Fig. 3-20. Con esta secuen cia, los movi mi entos 
del brazo son 1, 3, 7, 15, 33 y 2 para un total de 61 cilindros. Este algoritmo, la primera búsqueda más 
corta (SSF: shortest seekfirst), reduce el movimiento total del brazo casi a la mitad en comparación con 
FCFS. 


Desafortunadamente, SSF tiene un problema. Suponga que siguen llegando más peticiones mi entras 
se están procesando las peticiones de la Fig. 3-20. Por ejemplo, si, después de ir al cilindro 16 está 
presente una nueva petición para el cilindro 8, ésta tendrá prioridad sobre el cilindro 1. Si luego llega una 
petición para el cilindro 13, el brazo irá después a ese cilindro, en lugar de al 1. Si la carga del disco es 
elevada, el brazo tenderá a permanecer en la parte media del disco la mayor parte del tiempo, y las 
peticiones en los extremos tendrán que esperar hasta que una fluctuación estadística en la carga haga que 
no se presenten peticiones cerca de la parte media. Las peticiones alejadas de la parte media podrían 
recibir un servicio deficiente. Los objetivos de tiempo de respuesta mínimo y equitatividad están en 
conflicto aquí. 

Los edificios altos también tienen que enfrentar este trueque. El problema de planificar un elevador 
de un edificio alto es similar al de planificar un brazo de disco. Continuamente llegan llamadas que 
reclaman al elevador que se dirija a otros pisos al azar. El microprocesador que controla el elevador 
fácilmente podría usar FCFS para seguir la pista a la secuencia en que los clientes oprimen el botón de 
llamada y atenderlos; también podría usar SSF. 

Sin embargo, la mayor parte de los elevadores usan un algoritmo distinto para conciliar los 
objetivos en conflicto de eficiencia y equitatividad: continúan desplazándose en la misma dirección hasta 
que no hay más peticiones pendientes en esa dirección, y luego se mueven en la dirección opuesta. El 
algoritmo, conocido tanto en el mundo de los discos como en el de loselevadores como algoritmo del 
elevador, requiere que el software mantenga un bit: el bit de dirección actual, UPo DOWN. Cuando 
termina de atenderse una petición el controlador del disco o del elevador examina el bit. Si éste es UP, el 
brazo o el elevador se mueve a la petición pendiente más cercana hacia arriba. Si no hay peticiones 
pendientes en posiciones más altas, se invierte el bit de dirección. Si el bit está en DOWN, el movi mi ento 
es hacia la siguiente posición solicitada hacia abajo, si la hay. 

La Fig. 3-21 muestra el algoritmo del elevador usando las mismas siete peticiones que en la Fig. 3- 
20, suponiendo que el bit de dirección inicialmente estaba en UP. El orden en que se atienden los cilindros 
es 12, 16, 34, 36, 9 y 1, que produce movimientos del brazo de 1, 4, 18, 2, 27 y 8, para un total de 60 
cilindros. En este caso el algoritmo del elevador es un poco mejor que SSF, aunque usualmente es peor. 
Una propiedad agradable del algoritmo del elevador es que, dada cualquier colección de peticiones, el 
límite superior del movimiento total está fijo: no puede ser mayor que dos veces el número de cilindros, 

Una ligera modificación de este algoritmo que tiene una menor varianza en los tiempos de respuesta 
(Teory, 1972) consiste en siempre barrer en la misma dirección. Una vez atendida la petición pendiente 
para el cilindro de número más alto, el brazo se dirige al cilindro de número más bajo que tiene una 
petición pendiente y continúa moviéndose hacia arriba. En efecto, se considera que el cilindro de número 
más bajo está justo arriba del cilindro de número más alto. 
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Posición 

Inirial 

... MTT1 

0 5 10 15 20 25 30 35 Cilindro 



Figura 3-21. Algoritmo del elevador para planificar peticiones de disco. 


Algunos controladores de disco en hardware permiten al software determinar qué sector está 
actualmente bajo la cabeza. Con un controlador así, es posible otra optimación. Si están pendien tes dos o 
más peticiones para el mismo cilindro, el controlador puede solicitar que se lea a continuación el sector 
que va a pasar primero por la cabeza. Observe que cuando hay varias pistas en un cilindro, pueden 
atenderse sin retraso peticiones consecutivas para diferentes pistas. El controlador en hardware puede 
seleccionar cualquiera de sus cabezas instantáneamente, por que la selección de la cabeza no implica 
movimiento del brazo ni retraso rotacional. 

Con un disco duro moderno, la tasa de transferencia de datos es tan alta en comparación con la de 
un disco flexible que se requiere algún tipo de almacenamiento automático en caché. Por lo regular, 
cualquier petición de lectura de un sector hace que se lea ese sector y también una rarte del resto de la 
pista actual, o toda, dependiendo de cuánto espacio hay disponible en la mem caché del controlador. El 
disco de 540M descrito en la Fig. 3-19 tiene un caché de 64K o 128K. El controlador en hardware 
determina dinámicamente cómo se utilizará el caché. En su modalidad más simple, el caché se divide en 
dos secciones, una para leer y la otra para escribir. 

Si hay varias unidades de disco presentes, se debe mantener una tabla de peticiones pendien tes 
aparte para cada unidad. Siempre que una unidad está ociosa, se deberá ordenar a su brazo que se mueva 
al cilindro donde se le necesitará a continuación (suponiendo que el controlador permite búsquedas 
traslapadas). Una vez que termine la transferencia en curso, se podrá verificar si alguna unidad está 
colocada en el cilindro correcto. Si una o más lo están, se podrá iniciar una transferencia en una unidad 
cuya cabeza ya está en el cilindro correcto. Si ninguno de los brazos está en el lugar debido, el controlador 
deberá ordenar una nueva búsqueda a la unidad que acaba de completar una transferencia y esperar hasta 
la siguiente interrupción para ver cuál brazo llega a su destino primero. 


Manejo de errores 

Los discos en RAM no tienen que preocuparse por búsquedas ni optimación rotacional: en cualquier 
instante todos los bloques pueden leerse o escribirse sin ningún movi mi ento físico. Otra área en la que los 
discos en RAM son más sencillos que los reales es la de manejo de errores. Los discos en RAM siempre 
fúncionan; los reales no siempre lo hacen, pues están sujetos a una gran variedad de errores. Entre los más 
comunes están: 
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1. Error de programación (p. ej., petición de un sector inexistente). 

2. Error transitorio de suma de verificación (p. ej., causado por polvo en la cabeza). 

3. Error permanente de suma de verificación (p. ej., si un bloque de disco tiene un daño 
permanente). 

4. Error de búsqueda (p. ej., el brazo se envió al cilindro 6 pero fue al 7). 

5. Error de controlador en hardware (p. ej., el controlador se niega a aceptar comandos). 

Corresponde al controlador de disco en software manejar todos estos errores lo mejor que pueda. 

Ocurren errores de programación cuando el controlador en software le dice al controlador en 
hardware que busque un cilindro inexistente, lea de un sector inexistente, use una cabeza inexis tente o 
transfiera de o hacia memoria inexistente. La mayor parte de los controladores verifica los parámetros que 
se les proporcionan y protestan si no son válidos. En teoría, estos errores jamás deberían ocurrir, pero, 
¿qué debe hacer el controlador en software si el controlador en hardware indica que ha ocurrido uno? En 
el caso de un sistema hecho en casa, lo mejor es detenerse y exhibir un mensaje como “Llamar al 
programador” para que éste pueda rastrear el error y corregirlo. En el caso de un producto de software 
comercial que se usa en miles de sitios en todo el mundo, tal estrategia resulta menos atractiva. Tal vez lo 
único que puede hacerse es terminar la petición de disco actual con un error, y abrigar la esperanza de que 
no ocurra con demasiada frecuencia. 

Los errores de suma de verificación transitorios son causados por partículas de polvo del aire que se 
meten entre la cabeza y la superficie del disco. Casi siempre, estos errores pueden elimi narse repitiendo la 
operación unas cuantas veces. Si el error persiste, es preciso marcar el bloque como bloque defectuoso y 
evitarlo. 

Una forma de evitar los bloques defectuosos es escribir un programa muy especial que recibe una 
lista de bloques defectuosos como entrada y prepara cuidadosamente un archivo que confie ne todos esos 
bloques. Una vez creado este archivo, el asignador de disco creerá que todos esos bloques están ocupados 
y nunca los asignará. En tanto nadie trate de leer el archivo de bloques defectuosos, no habrá problemas. 

Impedir la lectura del archivo de bloques defectuosos no es cosa trivial. Muchos discos se respaldan 
copiando su contenido pista por pista en una cinta o unidad de disco de respaldo. Si se sigue este 
procedimiento, los bloques defectuosos causarán problemas. Respaldar el disco archivo por archivo es 
más lento pero resuelve el problema, siempre que el programa de respaldo conozca el nombre del archivo 
de bloques defectuosos y no lo copie. 

Otro problema que no puede resolverse con un archivo de bloques defectuosos es el de un bloque 
defectuoso en una estructura de datos del sistema de archivos que debe estar en un lugar fijo. Casi todos 
los sistemas de archivos tienen por lo menos una estructura de datos cuya posición es fija, a fin de poder 
encontrarla fácilmente. En un sistema de archivos dividido en particiones puede ser posible redefinir las 
particiones evitando una pista defectuosa, pero un error permanente en los prime ros sectores de un disco 
flexible o duro generalmente implica que el disco no puede usarse. 

Los controladores “inteligentes” reservan unas cuantas pistas que normalmente no están 
disponibles para los programas de usuario. Cuando se da formato a una unidad de disco, 
el controlador en hardware determina cuáles bloques están defectuosos y automáticamente sustituye 
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una de las pistas de repuesto por la defectuosa. La tabla que establece la correspondencia entre las pistas 
defectuosas y las de repuesto se mantiene en la memoria interna del controlador y en el disco. Esta 
sustitución es transparente (invisible) para el controlador en software, excepto que su algoritmo de 
elevador puede tener un rendimiento deficiente si el controlador en hardware está usando secretamente el 
cilindro 800 cada vez que se solicita el cilindro 3. La tecnología de fabri cación de las superficies de 
grabación de los discos es mejor que en el pasado, pero todavía no es perfecta. Por otro lado, la tecnología 
de ocultar las imperfecciones para que el usuario no las vea también ha mejorado. En los discos duros 
como el que se describe en la Fig 3-19, el controla dor también maneja los errores nuevos que pueden 
aparecer con el uso, asignando permanentemente bloques sustitutos cuando determina que un error es 
irremediable. Con tales discos, el controlador en software casi nunca recibe una indicación de que hay 
bloques defectuosos. 

Los errores de búsqueda son causados por problemas mecánicos en el brazo. El controlador en 
hardware sigue la pista a la posición del brazo internamente. Para realizar una búsqueda, el controlador 
envía una serie de pulsos al motor del brazo, un pulso por cilindro, a fin de desplazar el brazo al nuevo 
cilindro. Cuando el brazo llega a su destino, el controlador lee el número de cilindro real (que se escribió 
cuando se dio formato a la unidad. Si el brazo está en el lugar equivocado, habrá ocurrido un error de 
búsqueda. 

La mayor parte de los controladores de disco duro corrige tales errores automáticamente, pero 
muchos controladores de disco flexible (incluidos los de las IBM PC) simplemente ponen en 1 un bit de 
error y dejan el resto al controlador en software. Éste maneja el error emitiendo un comando 
RECALIBRATE que mueve el brazo hasta su posición exterior extrema y le indica al controlador en 
hardware que ahora está en el cilindro 0. Normalmente, esto resuelve el problema. Si no sucede así, será 
necesario reparar la unidad de disco. 

Como hemos visto, el controlador en hardware es en realidad una pequeña computadora 
especializada, completa con software, variables, buffers y, ocasionalmente, errores. A veces una secuencia 
inusual de sucesos, como la ocurrencia simultánea de una interrupción en una unidad y un comando 
RECALIBRATE para otra unidad causa un error y hace que el controlador entre en un ciclo u olvide qué 
es lo que estaba haciendo. Los diseñadores de controladores en hardware gene raímente planean pensando 
en lo peor que pueda suceder e incluyen una pata en el chip que, al recibir voltaje, obliga al controlador a 
olvidar lo que estaba haciendo y restablecerse. Si todo lo demás falla, el controlador en software del disco 
puede poner en 1 un bit para invocar esta señal y restablecer el controlador en hardware. Si esto no sirve 
de nada, todo lo que el controlador en software puede hacer es exhibir un mensaje y darse por vencido. 


Almacenamiento en caché de una pista a la vez 

El tiempo requerido para llevar el brazo a un nuevo cilindro normalmente es mucho más largo que el 
retraso rotacional, y siempre es mucho mayor que el tiempo de transferencia. Dicho de otro modo, una vez 
que el controlador se ha tomado la molestia de mover el brazo a algún lugar, poco importa 
si se lee un sector o toda una pista. Esto es así sobre todo si el controlador en hardware 
cuenta con detección rotacional, de modo que el controlador en software puede saber 
cuál sector está actualmente bajo la cabeza y solicitar el siguiente sector, pudiendo así leer una pista en el 
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tiempo que tarda una rotación. (Normalmente se requiere media rotación más un tiempo de sector para 
leer un solo sector, en promedio.) 

Algunos controladores de disco en software aprovechan esta propiedad manteniendo un caché 
secreto donde guardan una pista a la vez; el software independiente del dispositivo no sabe que este caché 
existe. Si se necesita un sector que está en el caché, no se requerirá una transferencia de disco. Una 
desventaja del almacenamiento de una pista a la vez en caché (además de la complejidad del software y 
del espacio de buifer requerido) es que las transferencias del caché al programa invocador deben ser 
efectuadas por la CPU usando un ciclo programado, en lugar de dejar que el hardware de DMA se 
encargue del trabajo. 

Algunos controladores en hardware llevan este proceso aún más lejos, y guardan una pista a la vez 
en su propia memoria interna sin que el controlador en software tenga conocimiento de ello; así, la 
transferencia entre el controlador y la memoria puede utilizar DMA. Si el controlador en hardware trabaja 
de este modo, no tiene caso hacer que el controlador en software también lo haga. Cabe señalar que tanto 
el controlador en hardware como en software están en condiciones de leer y escribir pistas completas con 
un solo comando, pero el software independiente del dispositivo no puede hacerlo, porque considera a un 
disco como una secuencia lineal de bloques que no está dividida en pistas ni cilindros. 


3.7.3 Generalidades del controlador de disco duro en MINIX 

El controlador en software del disco duro es la primera parte de MINIX que hemos examinado que 
necesita tratar con una amplia variedad de tipos de hardware distintos. Antes de entrar en los detalles del 
controlador, consideraremos brevemente algunos de los problemas que las diferencias de hardware pueden 
causar. La “IBM PC” es en realidad una familia de computadoras distintas. No sólo se usan diferentes 
procesadores en diferentes miembros de la familia; también hay diferencias importantes en el hardware 
básico. Los primeros miembros de la familia, la PC original y la PC-XT, usaban un bus de 8 bits, 
apropiado para la interfaz externa de 8 bits del procesador 8088. La siguiente generación, la PC-AT, usaba 
un bus de 16 bits, diseñado ingeniosamente de modo que los periféricos viejos de 8 bits pudieran seguirse 
usando. Sin embargo, los periféricos más nuevos de 16 bits generalmente no pueden usarse en los sistemas 
PC-XT más viejos. El bus AT se diseñó originalmente para sistemas que usaban el procesador 80286, y 
muchos sistemas basados en 80386, 80486 y Pentium usan el bus AT. Sin embargo, dado que estos 
procesadores más nuevos tienen una interfaz de 32 bits, ya hay varios sistemas con bus de 32 bits 
disponibles, como el bus PCI de Intel. 

Para cada bus hay una familia distinta de adaptadores de E/S, que se conectan a la tarjeta matriz del 
sistema. Todos los periféricos para un diseño de bus en particular deben ser compatibles con las normas 
para ese diseño pero no tienen que ser compatibles con diseños más viejos, En la familia IBM PC, al igual 
que en la mayor parte de los sistemas de computadora más viejos, cada diseño de bus 
viene acompañado de firmware en la memoria sólo de lectura del sistema básico de E/S 
(la BIOS ROM) diseñado para salvar la brecha entre el sistema operativo y las 
peculiaridades del hardware. Algunos dispositivos periféricos pueden incluir extensiones del 
BIOS en chips de ROM montados en las tarjetas de los mismos dispositivos. La dificultad que enfrenta un 
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implementador de sistemas operativos es que el BIOS en las computadoras tipo IBM (ciertamente en las 
primeras) estaba diseñado para un sistema operativo, MS-DOS, que no reconoce la multiprogramación y 
que se ejecuta en modo real de 16 bits, el mínimo común denominador de los diversos modos de 
operación de los miembros de la familia de CPU 80x86. 

Así, el implementador de un nuevo sistema operativo para la IBM PC enfrenta varias decisio nes. 
Una es si usará el apoyo de controladores en software para periféricos que viene en el BIOS o escribirá 
nuevos controladores desde cero. Esta decisión no fue difícil en el diseño original de MINIX, ya que el 
BIOS no era adecuado en muchos aspectos para las necesidades de MINIX. Desde luego, para iniciar, el 
monitor de arranque de MINIX utiliza el BIOS para efectuar la carga inicial del sistema, sea de un disco 
duro o un disquete, pues no existe una alternativa práctica. Una vez cargado el sistema, que incluye 
nuestros propios controladores de E/S, podemos hacer las cosas mucho mejor que con el BIOS. 

A continuación enfrentamos la segunda decisión: sin el apoyo del BIOS, ¿cómo vamos a hacer que 
nuestros controladores en software se adapten a las diversas clases de hardware de los diferentes sistemas? 
En términos concretos, consideremos que hay por lo menos cuatro tipos fundamentalmente distintos de 
controladores de disco duro en hardware que podríamos encon trar en un sistema que por lo demás es 
adecuado para MINIX: el controlador original de 8 bits tipo XT, el controlador de 16 bits tipo AT y dos 
controladores diferentes para dos tipos distintos de computadoras de la serie IBM PS/2. Hay varias formas 
posibles de resolver esto: 

1. Recompilar una versión distinta del sistema operativo para cada tipo de controlador de disco 
duro que tengamos que manejar. 

2. Compilar varios controladores en software distintos en el kemel y hacer que éste determine 
automáticamente en el momento de arrancar cuál debe usarse. 

3. Compilar varios controladores en software distintos en el kemel y proveer un me canismo para 
que el usuario determine cuál se usará. 

Como veremos, estas formas no son mutuamente exclusivas. 

La primera forma es realmente la mejor a largo plazo. Si se usa en una instalación específica, no 
hay necesidad de gastar espacio de disco y de memoria en código para otros controladores que nunca se 
usarán. Sin embargo, este enfoque es una pesadilla para el distribuidor del software, pues proveer cuatro 
discos de arranque distintos y enseñar a los usuarios a utilizarlos es costoso y difícil. Por ello, es 
aconsejable usar una de las otras alternativas, al menos para la instalación inicial. 

El segundo método consiste en hacer que el sistema operativo sondee los periféricos, ya sea 
leyendo el ROM de cada tarjeta o escribiendo en los puertos de E/S y leyéndolos a fin de identifi car cada 
tarjeta. Esto es factible en algunos sistemas pero no funciona bien en los sistemas tipo IBM porque hay 
demasiados dispositivos de E/S no estándar disponibles. En algunos casos, el sondeo de los puertos de E/S 
para identificar un dispositivo puede activar otro dispositivo que se adueña del control e inhabilita el 
sistema. Este método complica el código de arranque para cada dispositivo, y aun así, no funciona muy 
bien. Los sistemas operativos que emplean este método generalmente tienen que proveer algún 
mecanismo de anulación como el que se usa en MINIX. 

El tercer método, empleado en MINIX, consiste en permitir la compilación de varios 
controladores en soíware, siendo uno de ellos el predeterminado. El monitor de arranque de MINIX 
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permite leer diversos parámetros de arranque durante la iniciación, los cuales pueden introducirse a mano 
o almacenarse permanentemente en el disco. Durante el inicio, si se encuentra un parámetro de arranque 
de la forma 

hd=xt 

se usará el controlador de disco duro XT. Si no se encuentra un parámetro de arranque hd, se usa el 
controlador predeterminado. 

Hay otras dos cosas que MINIX hace para tratar de minimizar los problemas causados por la 
presencia de múltiples controladores de disco duro. Una es proveer un controlador que sirve como interfaz 
entre MINIX y el apoyo de disco duro de ROM BIOS. Este controlador funciona prácticamente en todos 
los sistemas y se puede seleccionar usando 

hd bios 

como parámetro de arranque. No obstante, esto debe considerarse casi siempre como último recurso. 
MINIX se ejecuta en modo protegido en los sistemas con procesador 80286 o superior, pero el código del 
BIOS siempre se ejecuta en modo real (8086). La salida del modo protegido y el regreso posterior a él 
cada vez que se invoca una rutina del BIOS es algo muy lento. 

La otra estrategia que MINIX usa para trabajar con los controladores en software es posponer la 
inicialización hasta el último momento. De este modo, si en alguna configuración de hardware ninguno de 
los controladores de disco duro en software funciona, aún podremos iniciar MINIX desde un disco 
flexible y realizar algo de trabajo útil. MINIX no tendrá problemas en tanto no se trate de acceder al disco 
duro. Esto tal vez no sea lo máximo en cuanto a amabilidad con el usuario, pero considere lo siguiente: si 
todos los controladores en software tratan de inicializarse de inmediato durante el arranque del sistema, 
éste puede paralizarse si algún dispositivo que ni siquiera necesitamos no está bien configurado. Al 
posponer la inicialización de cada controlador en software hasta que se le necesite, el sistema puede 
continuar con lo que sí fúnciona, mientras el usuario trata de resolver los problemas. 

Como acotación, aprendimos esta lección e la manera difícil: las primeras versiones de MINIX 
trataban de inicializar el disco duro tan pronto como se arrancaba el sistema. Si no había disco duro 
presente, el sistema se paralizaba. Este comportamiento era doblemente molesto porque MINIX puede 
funcionar perfectamente en un sistema sin disco duro, si bien con capacidad de almacenamiento 
restringida y menor eficiencia. 

En las explicaciones de esta sección y la siguiente, usaremos como modelo el controlador de disco 
duro tipo AT, que es el controlador en software predeterminado en la distribución de MINIX estándar. Se 
trata de un controlador versátil que maneja controladores en hardware desde los que se usaban en los 
primeros sistemas 80286 hasta los modernos controladores EIDE (Extended Integrated Drive Electronics) 
que manejan discos duros con capacidad de gigabytes. Los aspectos generales del funcionamiento del 
disco duro que veremos en esta sección se aplican también a los demás controladores en software 
reconocidos. 

El ciclo principal de la tarea del disco duro es el mismo código compartido que ya analizamos, y 
pueden efectuarse las sE/S peticiones estándar. Una petición DEV OPEN puede implicar mucho trabajo, 
ya que siempre hay particiones y puede haber subparticiones en un disco duro. Estas 
particiones deben leerse cuando se abre un dispositivo (esto es, cuando se accede a él por primera vez). 
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Algunos controladores en hardware de disco duro también pueden manejar unidades de CD-ROM, que 
tienen medios removibles, y cuando se emite una petición DEVOPEN se debe verificar la ptesencia del 
medio. En un CD-ROM también tiene significado una operación DEVCLOSE: exige que la puerta se 
abra y se expulse el disco. Existen otras complicaciones de los medios removibles que s más aplicables a 
los discos flexibles, así que las veremos en una sección posterior. En el caso del disco duro, la operación 
DEV IOCTL sirve para establecer una bandera que indica que el medio delerá expulsarse cuando se emita 
una petición DEV CLOSE. Esta capacidad es útil para los CD ROM, y también se usa para leer y escribir 
tablas de particiones, como señalamos antes. 

Las peticiones DEV READ, DEV WRJTE y SCA TTEREDJO se manejan en tres fases cada 
una: preparar, planificar y terminar, como ya vimos. El disco duro, a diferencia de los dispositivos de 
memoria, distingue claramente entre las fases de planificación y terminación. El controlador en software 
del disco duro no usa SSF ni el algoritmo de elevador, sino que realiza una forma más limitada de 
planificación, recabando peticiones para sectores consecutivos. Las peticiones normal mente provienen del 
sistema de archivos MINIX y se refieren a múltiplos de bloques de 1024 bytes, pero el controlador puede 
atender peticiones de cualquier múltiplo de un sector (512 bytes). En tanto cada petición sea para un sector 
inicial que sigue inmediatamente al último sector solicitado, cada petición se anexará al final de una lista 
de peticiones. La lista se mantiene como un arreglo, y cuando se llena, o cuando se solicita un sector no 
consecutivo, se invoca la rutina de terminación. 

En una petición DEV READ o DEV WRITE sencilla, podría solicitarse más de un bloque, pero 
cada llamada a la rutina de planificación va seguida inmediatamente de una llamada a la rutina de 
terminación, lo que asegura que se cumpla con la lista de peticiones vigente. En el caso de una petición 
SCATTERED IO, puede haber múltiples llamadas a la rutina de planificación antes de invocarse la rutina 
de terminación. En tanto las peticiones sean para bloques de datos con secutivos, la lista se extenderá hasta 
que el arreglo se llene. Recuerde que en una petición SCATI’ERED JO una bandera puede indicar que la 
petición de un bloque en particular es opcio nal. El controlador en software del disco duro, al igual que el 
de la memoria, hace caso omiso de la bandera OPTIONAL y suministra todos los datos solicitados. 

La planificación rudimentaria realizada por el controlador en software del disco duro, pospo 
mendo las transferencias reales mi entras se estén solicitando bloques consecutivos, debe verse como el 
segundo paso de un proceso de planificación que potencialmente tiene tres pasos. El sistema de archivos 
mismo, al usar E/S dispersa, puede implementar algo similar a la versión de Teory del algoritmo del 
elevador; recuérdese que, en una petición de E/S dispersa, la lista de peticiones se ordena por número de 
bloque. El tercer paso de la planificación tiene lugar en el controlador en hardware de un disco duro 
moderno como el que se describió en la Fig. 3-19. Tales controladores son “inteligentes” y pueden 
almacenar en buffers grandes cantidades de datos, usando algoritmos programados internamente para 
recuperar los datos en el orden más eficiente, sea cual sea el orden en que se hayan recibido las peticiones. 


3.7.4 Implementación del controlador de disco duro en MINIX 

Los discos duros pequeños que se usan en las microcomputadoras a veces se deno mi nan 
discos “Winchester”. Hay varias anécdotas diferentes acerca del origen de este nombre. Al parecer, IBM 
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usaba este nombre como código para el proyecto que desarrolló la tecnología de disco en la que las 
cabezas de lectura/escritura vuelan sobre un delgado colchófl de aire y se posan sobre el medio de 
grabación cuando el disco deja de girar. Una explicación del nombre es que uno de los primeros modelos 
tenía dos módulos de datos: uno fijo de 30 Mbytes y uno removible de 30 Mbytes. Supuestamente, esto 
recordaba a los diseñadores el rifle Winchester 30-30 que se menciona en muchas narraciones de la 
frontera oeste de Estados Unidos. Sea cual sea el ongen del nombre, la tecnología básica sigue siendo la 
misma, aunque los discos duros de microcomputadora actuales son mucho más pequeños y su capacidad 
es mucho mayor que la de los discos de 14 pulgadas que se usaban a principios de la década de 1970 
cuando se creó la tecnología Winchester. 

El archivo wini. c se encarga de ocultar del resto del kemel el controlador de disco duro real que se 
usará. Esto nos permite seguir la estrategia delineada en la sección anterior, compilando varios 
controladores de disco duro en una sola imagen del kemel y seleccionando el que se usará en el momento 
del arranque. Posteriormente se puede compilar una instalación a la medida que sólo incluya el 
controlador que realmente se necesita. 

Wini.c contiene una definición de datos, hdmap (línea 10013), un arreglo que asocia un nombre con 
la dirección de una función. El compilador inicializa el arreglo con tantos elementos como se necesiten 
para el número de controladores de disco duro habilitados en includelminix/config.h. El arreglo es 
utilizado por la función winchestertask, que es el nombre, contenido en la tabla task tab, que se usa 
cuando se inicializa el kemel. Cuando se invoca winchester task (línea 10040), trata de encontrar una 
variable de entorno hd, usando una función del kemel que opera de forma parecida al mecanismo 
empleado por los programas en C ordinarios, leyendo el entorno creado por el monitor de arranque 
MINIX. Si no se define ningún valor hd, se usa la primera entrada del arreglo; de lo contrario, se busca en 
el arreglo un nombre concordante, y luego se invoca indirectamente la fúnción correspondiente. En el 
resto de esta sección examinaremos atwinchestertask, que es la primera entrada del arreglo hdmap en la 
distribución estándar de MINIX. 

El controlador en software para AT está en atwini.c (línea 10100). Éste es un controlador 
complicado para un dispositivo avanzado, y hay varias páginas de definiciones de macros que especifican 
registros del controlador en hardware, bits de estado y comandos, estructuras de datos y prototipos. Al 
igual que en otros controladores de dispositivos por bloques, se inicializa una estructura driver, w dtab 
(líneas 10274 a 10284) con apuntadores a las funciones que realizan el verdadero trabajo. La mayor parte 
de éstas se definen en at wini.c, pero como el disco duro no requiere operaciones de aseo especiales, su 
entrada dr cleanup apunta a la fúnción común nop cleanup en drive,:c, misma que comparten otros 
dispositivos que no tienen necesidades de aseo especiales. La función de entrada, at winchester task 
(línea 10294), invoca un procedimiento que realiza la inicialización específica para el hardware y luego 
invoca el ciclo principal de driver.c. Éste se ejecuta indefinidamente, despachando llamadas a las diversas 
fruiciones a las que se apunta en la tabla driver, 

Puesto que ahora estamos tratando con dispositivos de almacenamiento electromecánicos reales, 
debemos realizar una cantidad sustancial de trabajo para inicializar el controlador en software 
del disco duro. Diversos parámetros de los discos duros se mantienen en el arreglo wini definido 
en las líneas 10214 a 10230. Como parte de la política de posponer los pasos de inicialización 
que pudieran fallar hasta el momento en que se necesiten realmente, initparams (línea 10307), 
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que se invoca durante la inicialización del kemel, no hace nada que requiera acceder al dispositivo del 
disco mismo. Lo principal que hace es copiar cierta información referente a la configuración lógica del 
disco duro en el arreglo wini. Se trata de información que elTROM BIOS obtiene de la memoria CMOS 
que las computadoras clase Pentium usan para preservar los datos de configura ción básicos. Las acciones 
del BIOS tienen lugar cuando se enciende in icialmente la computado ra, antes de comenzar la primera 
parte del proceso de carga de MINIX. Si esta información no puede recuperarse, las consecuencias no son 
necesariamente fatales; si se trata de un disco moderno, la información podrá obtenerse directamente del 
disco. 


Después de la llamada al ciclo principal común, es posible que nada suceda durante algún tiempo 
hasta que se intente acceder al disco duro. Entonces se recibirá un mensaje solicitando una operación DE 
V OPEN y se invocará indirectamente wdoopen (línea 10355). A su vez, wdoopen invoca w_prepare 
para determinar si el dispositivo solicitado es válido, y luego w identzfy para identificar el tipo de 
dispositivo e inicializar algunos parámetros más del arreglo wini. Por último, se usa un contador del 
arreglo wini para probar si ésta es la primera vez que se ha abierto el dispositivo desde que se inició 
MINIX. Después de examinarse, el contador se incrementa. Si se trata de la primera operación 
DEV...OPEN, se invoca la función partition (de drvlib.c). 

La siguiente función, w_prepare (línea 10388) acepta un argumento entero, device, que es el número 
de dispositivo secundario de la unidad o partición que se usará, y devuelve un apuntador a la estructura 
device que indica la dirección base y el tamaño del dispositivo. En C el empleo de un identificador para 
nombrar una estructura no impide el uso del mismo identificador para nombrar una variable. Se puede 
determinar, a partir del número de dispositivo secundario, si un dispositivo es una unidad, una partición o 
una subpartición. Una vez que w_prepare haya com pletado su trabajo, ninguna de las demás funciones 
empleadas para leer o escribir en el disco tendrán que preocuparse por la división en particiones. Como 
hemos visto, se invoca w_prepare cuando se hace una petición DEV OPEN; también es una fase del ciclo 
preparar/planificar/termi nar empleado por todas las peticiones de transferencia de datos. En ese contexto, 
su inicialización de w count en cero es importante. 

Los discos tipo AT compatibles por software han estado en uso durante mucho tiempo, y w identify 
(línea 10415) tiene que distinguir entre varios diseños diferentes que se han introducido a lo largo del 
tiempo. El primer paso consiste en comprobar que exista un puerto de E/S legible y escribible en el lugar 
en el que debe haber uno en todos los controladores de disco en hardware de esta familia (líneas 10435 a 
10437). Si se satisface esta condición, la dirección del manejador de interrupciones de disco duro se 
instala en la tabla de descriptores de interrupciones y se inhabilita el controlador de interrupciones para 
que responda a esa interrupción. Luego se emite un comando ATA IDENTIFY al controlador en 
hardware del disco. Si el resultado es OK, se obtienen varios elementos de información, incluida una 
cadena que identifica el modelo del disco y los parámetros físicos de cilindro, cabeza y sector del 
dispositivo. (Cabe señalar que la configuración “física” informada podría ser diferente de la configuración 
física verdadera, pero no tenemos más altemati va que aceptar lo que la unidad de disco asegura.) La 
información del disco también indica si el disco puede o no manejar direccionamiento lineal de bloques 
(LBA: linear biock addressing). Si puede, el controlador en software puede hacer caso omiso de los 
parámetros de cilindro, cabeza y sector y direccionar el disco usando números de sector absolutos, lo cual 
es mucho más sencillo. 
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Como mencionamos antes, es posible que init_params no recupere la información de configuración 
lógica del disco de las tablas del BIOS. Si eso sucede, el código de las líneas 10469 a 10477 intenta crear 
un conjunto de parámetros apropiado con base en lo que lee de la unidad de disco misma. La idea es que 
los números de cilindro, cabeza y sector máximos pueden ser 1023, 255 y 63, respectivamente, en virtud 
del número de bits destinado a cada uno de estos campos en las estructuras de datos originales del BIOS. 

Si el comando ATA JDENTIFY falla, esto puede implicar sencillamente que el disco es un modelo 
viejo que no reconoce el comando. En este caso lo único que tenemos son los valores de configuración 
lógica que init_params leyó antes. Si tales parámetros son válidos, se copian en los campos de parámetros 
físicos de wini; si no, sedevuelve un error y no se puede usar el disco. 

Por último, MINIX emplea una variable llamada u32_t para contar direcciones en bytes. El tamaño 
de dispositivo que el controlador en software puede manejar, expresado como número de sectores, debe 
limitarse si el producto de cilindros x cabezas x sectores es demasiado grande (línea 10490). Aunque en el 
momento de escribirse este código era raro encontrar dispositivos con capacidad de 4 GB en máquinas que 
esperaríamos se usaran con MINIX, la experiencia ha demos trado que el software debe escribirse de 
modo que pruebe lí mi tes como éste, por inn ecesarias que tales pruebas parezcan en el momento de 
escribirse el código. Luego, se introducen la base y el tamaño de toda la unidad en el arreglo wini y se 
invoca w specify, dos veces si es necesario, a fin de pasar los parámetros que se usarán de vuelta al 
controlador en software del disco. Por último, se exhiben en la consola el nombre del dispositivo 
(determinado por wname) y la cadena de identificación obtenida mediante identify (si se trata de un 
dispositivo avanzado) o los parámetros de cilindro, cabeza y sector informados por el BIOS (si se trata de 
un dispositivo viejo). 

W name (línea 10511) devuelve un apuntador a una cadena que contiene el nombre de dispo sitivo, 
que será “at-hdO”, “at-hd5”, “at-hdlO” o “at-hdlS”. W specify (línea 10531), además de pasar los 
parámetros al controlador, recalibra la unidad de disco (si se trata de un modelo viejo) buscando el 
cilindro cero. 

Ahora estamos listos para analizar las funciones que se invocan al satisfacer una petición de 
transferencia de datos, W_prepare, que ya explicamos, es la que se invoca primero. Su inicialización de la 
variable wcount en cero es importante aquí. La siguiente fúnción que se invoca durante una transferencia 
es w schedule (línea 10567), la cual establece los parámetros básicos: de dónde provienen los datos, a 
dónde deben ir, el número de bytes por transferir (que debe ser un múltiplo del tamaño de sector, y se 
prueba en la línea 10584), y si la transferencia es una lectura o una escritura. El bit que puede estar 
presente en una petición SCAITERED IO para indicar una transfe rencia opcional se pone en O en el 
código de operación que se pasará al controlador en hardware (línea 10595), pero obsérvese que se 
conserva en el campo io request de la estructura iorequest s. En el caso del disco duro, se intenta 
satisfacer todas las peticiones pero, como veremos, el controla dor en software puede decidir 
posteriormente no hacerlo si han ocurrido errores. La última acción de la preparación es verificar que la 
petición no rebase el último byte del dispositivo y reducir la peti ción si así fuera. En este punto se puede 
calcular el primer sector que se leerá. 

En la línea 10602 comienza el proceso de planificación propiamente dicho. Si ya hay 
peticiones pendientes (lo que se prueba viendo si w count es mayor que cero), y si el sector que 
se leerá a continuación no es el que sigue al último que se solicitó, se invoca wjinish para completar las 
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peticiones previas. En caso contrario, se actualiza wnextblock, que contiene el número del siguiente 
sector, y se ingresa en el ciclo de las líneas 10611 a 10640 .para agregar nuevas peticiones de sectores al 
arreglo de peticiones hasta alcanzar el número máximo permisible de peticiones (línea 10614). El límite se 
guarda en una variable llamada maxcount pues, como veremos más adelan te, hay ocasiones en que 
resulta útil poder ajustar el lí mi te. Aquí también el resultado puede ser una llamada a wfinish. 

Como hemos visto, hay dos lugares dentro de w_ prepare donde puede efectuarse una llama da a 
w finish. Normalmente, w_prepare ter mi na sin invocar w fin ish pero, sea que se invoque desde 
w_prepare o no, wfinish (línea 10649) siempre se invoca tarde o temprano desde el ciclo principal de 
driver.c. Si acaba de invocarse otra vez, es posible que no tenga trabajo que hacer, por lo que se efectúa 
una prueba en la línea 10659 para comprobar esto. Si todavía hay peticiones en el arreglo de peticiones, se 
ingresa en la parte principal de wfinish. 

Como era de esperar, dado que puede haber un número considerable de peticiones encoladas, la parte 
principal de wfinish es un ciclo, en las líneas 10664 a 10761. Antes de entrar en el ciclo, se preestablece 
la variable r en un valor que indica un error, a fin de obligar a la reinicialización del controlador en 
hardware. Si una llamada a w specify tiene éxito, se inicializa la estructura command cmd para realizar 
una transferencia. Esta estructura sirve para pasar todos los parámetros necesa ríos a la fúnción que opera 
realmente el controlador de disco en hardware. Algunas unidades utilizan el parámetro cmd.precomp para 
compensar las diferencias en el rendimiento del medio de grabación magnético cuando hay diferencias en 
la velocidad con que el medio pasa bajo las cabezas del disco conforme éstas se mueven de los cilindros 
exteriores a los interiores. Este parámetro siempre es el mismo para una unidad en particular y muchas 
unidades hacen caso omiso de él. Cmd.count recibe el número de sectores por transferir, enmascarado 
para dar una cantidad que quepa en un byte de 8 bits, ya que éste es el tamaño de todos los registros de 
comandos y estado del controlador en hardware. El código de las líneas 10675 a 10689 especifica el 
primer sector por transferir, ya sea como un número de bloque lógico de 28 bits (líneas 10676 a 10679) o 
como parámetros de cilindro, cabeza y sector (líneas 10681 a 10688). En ambos casos se usan los mismos 
campos de la estructura cmd. 

Por último se carga el comando mismo, leer o escribir, y se invoca comout en la línea 10692 para 
iniciar la transferencia. La llamada a com out puede fallar si el controlador en hardware no está listo o no 
queda listo dentro de un lapso preestablecido. En este caso se incrementa el conteo de errores y se aborta 
el intento si se alcanza MAXERRORS. En caso contrario, la instrucción 

continué; 

de la línea 10697 hace que el ciclo se inicie otra vez en la línea 10665. 

Si el controlador en hardware acepta el comando que se pasa en la llamada a com out, puede pasar 
cierto tiempo antes de que los datos estén disponibles, así que (suponiendo que el comando es 
DEV READ) se invoca wintrwait en la línea 10706. Estudiaremos con detalle esta fúnción más 
adelante, pero por ahora bastará con tomar nota de que invoca a receive, de modo que en este punto la 
tarea de disco se bloquea. 

Cierto tiempo después, largo o corto dependiendo de si fue necesario o no mover el 
brazo, la llamada a w intr wait regresará. Este controlador en software no utiliza DMA, aunque algunos 
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controladores lo reconocen. En vez de ello, se usa E/S programada. Si wintrwait no devuelve ningún 
error, la función en lenguaje ensamblador portread tr SECTORSIZE bytes de datos del puerto de datos 
del controlador en hardware a su destino final, que debe ser un buffer en el caché de bloques del sistema 
de archivos. A continuación se ajustan diversas direcciones y contadores pasa registrar la transferencia 
realizada con éxito. Por último, si la cuenta de bytes de la petición en curso llega a cero, el apuntador al 
arreglo de peticiones se avanza de modo que apunte a la siguiente petición (línea 10714). 

En el caso de un comando DEV WRITE, la primera parte, es decir, preparar los parámetros del 
comando y enviar el comando al controlador en hardware, es la misma que para una lectura, excepto por 
el código de operación del comando. Sin embargo, el orden de los sucesos subsecuentes es diferente para 
una escritura. Primero hay una espera hasta que el controlador en hardware indica mediante una señal que 
está listo pasa recibir datos (línea 10724). Waitfor es una macro, y normalmente regresa con gran rapidez. 
Hablaremos más de esta macro después; por ahora sólo apuntaremos que el tiempo de espera finalmente 
se vence, y que se espera que las esperas largas sean extremadamente raras. Luego, los datos se transfieren 
de la memoria al puerto de datos del controlador en hardware usando port write (línea 10729), y en este 
punto se invoca w intr wait y la tarea de disco se bloquea. Cuando llega la interrupción y la tarea de disco 
se despierta, se realiza la contabilización (líneas 10736 a 10739). 

Por último, si ha habido errores al leer o escribir, deben manejarse. Si el controlador en hardware 
informa al controlador en software que el error fue causado por un sector defectuoso, no tiene caso 
intentarlo otra vez, pero otros tipos de errores sí valen la pena reintentarse, al menos hasta cierto punto, el 
cual se determina contando los errores y dándose por vencido se se llega a MAX ERRORS. Cuando se 
llega a MAX se invoca w need reset para forzar la reinicialización cuando se efectúa el reintento. Sin 
embargo, si la petición originalmente era opcio nal (hecha con SCA7TERED10), no hay reintento. 

Sea que w termine sin errores o a causa de un error, siempre se asigna el valor de CMD IDLE a 
w command. Esto permite a otras funciones determinar que el fallo no se debió a un problema mecánico 
o eléctrico del disco mismo, impidiendo la generación de una interrupción después de una operación 
intentada. 

El controlador en hardware del disco se maneja mediante un conjunto de registros, que en algunos 
sistemas pueden tener una correspondencia con la memoria pero que, en las máquinas compatibles con 
IBM, aparecen como puertos de FIS. Los registros empleados por un controla dor en hardware de disco 
duro de clase IBM-AT se muestran en la Fig. 3-22. 

Éste es nuestro primer encuentro con hardware de E/S, y puede resultar útil mencionar algunas de las 
diferencias de comportamiento entre los puertos de E/S y las direcciones de memo ria. En general, los 
registros de entrada y de salida que tienen la misma dirección de puerto de E/S no son el mismo 
registro. Por tanto, los datos escritos en una dirección específica no necesariamente pueden 
recuperarse con una operación de lectura subsecuente. Por ejemplo, la última dirección de 
registro que se muestra en la Fig. 3-22 indica el estado del controlador en hardware del disco cuando se 
lee y sirve para emitir comandos al controlador cuando se escribe en ella. También es comtin 
que el mero acto de leer o escribir en un registro de dispositivo de FIS cause la realización 
de una acción, con independencia de los detalles de los datos transferidos. Esto es cierto en el 
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Registro 

Función de lectura 

FuncMp de escritura 

0 

Datos 

Datos 

1 

Error 

Precompensación de escritura 

2 

Cuenta de sectores 

Cuenta de sectores 

3 

Número de sector (0-7) 

Número de sector (0-7) 

4 

Cilindro bajo (8-15) 

Cilindro bajo (8-15) 

5 

Cilindro alto (16-23) 

Cilindro alto (16-23) 

6 

Seleccionar unidad/cabeza (24-27) 

Seleccionar umdad/cabeza (24-27) 

7 

Estado 

Comando 


(a) 



[ 6 1 

5 

nrrri 

2 

1 | 

o] 

1 i 1 

J.BA 1 

lU 

i d i 1 * 3 

HS2 

HS1 

HS0| 


LBA: 0 = Modo dhndro/cabeza/seclof (CHS) 

1 s Modo de direccionamíento por bloque lógico (LBA) 
D: 0 * Unidad maestra 

1 = Unidad esclava 

HSn: Modo CHS; Selección de cabeza en modo CHS 
Modo LBA; Bits de selección de bloque 24-27 


Figura 3-22. (a) Registros de control de un controlador en hardware de disco duro IDE. Los 
números entre paréntesis son los bits de la dirección de bloque lógico seleccionada por cada 
registro en modo LBA. (b) Campos del registro de selección de unidad/cabeza. 


caso del registro de comando del controlador de disco AT. En uso, se escriben datos en los registros de 
números más bajos para seleccionar la dirección de disco que se leerá o en la que se escribirá, y luego se 
escribe al final el registro de comando con un código de operación. El acto de escribir el código de 
operación en el registro de comando inicia la operación. 

También sucede que el uso de algunos registros o campos de registros varíe con los diferen tes 
modos de operación. En el ejemplo que se da en la figura, la escritura de un O o un 1 en el bit de LBA (bit 
6 del registro 6) selecciona el empleo del modo CHS (cilindro-cabeza-sector) o LBA (direccionamiento de 
bloque lógico). Los datos que se escriben en o se leen de los registros 3, 4 y 5 y los cuatro bits bajos del 
registro 6 se interpretan de manera diferente dependiendo del valor del bit de LBA. 
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Veamos ahora cómo se envía un comando al contro en hardware invocando comout (línea 10771). 
Antes de modificar ningún registro, se lee el registro de estado para verificar que el controlador no esté 
ocupado. Esto se hace probando el bit STATUSBSY. Aquí es importante la rapidez, y normalmente el 
controlador de disco está listo o estará listo en un tiempo corto, por lo que se emplea espera activa. En la 
línea 10779 se invoca waitfor para probar STATUS BSY. A fin de maximizar la rapidez de respuesta, 
waitfor es una macro, definida en la línea 10268. Esta macro realiza la prueba requerida una vez, evitando 
una costosa llamada de función en la mayor parte de las invocaciones, cuando el disco está listo. En las 
raras ocasiones en que es necesaria una espera, la macro llama a wwaitfor, que ejecuta la prueba en un 
ciclo hasta que el resultado es verdadero o se vence un periodo de espera predefinido. Así, el valor 
devuelto será verdadero con el retraso mínimo posible si el controlador está listo, verdadero después de un 
retraso si temporal mente no está disponible, o falso si no está listo después del periodo de espera. 
Hablaremos más acerca del tiempo de espera cuando estudiemos w waitfor en sí. 

Un controlador en hardware puede manejar más de una unidad de disco, así que una vez que se 
determina que el controlador está listo se escribe un byte para seleccionar la unidad, la cabeza y el modo 
de operación (línea 10785) y luego se invoca otra vez waitfor. Hay ocasiones en que una unidad de disco 
no lleva a cabo un comando ni devuelve un código de error correcto —después de todo, es un dispositivo 
mecánico que se puede atorar, atascar o descomponer internamente— y como seguro se envía un mensaje 
a la tarea de reloj para planificar una llamada a una rutina de despertar. Después de esto, se emite el 
comando escribiendo primero todos los parámetros en los diversos registros y, finalmente, el código del 
comando mismo en el registro de comando. Este último paso y la subsecuente modificación de las 
variables wcommand y w status forman una sección crít ica, así que toda la secuencia está flanqueada 
por llamadas a lock y unlock (líneas 10801 a 10805) que inhabilitan y luego habilitan las interrupciones. 

Las siguientes funciones son cortas. Ya vimos que wneedreset (línea 10813) es invocada por 
w finish cuando el conteo de fallas llega a la mitad de MAXERRORS; también se invoca cuando se 
vencen tiempos de espera para que el disco genere una interrupción o quede listo. La acción de 
w need reset sólo consiste en marcar la variable State para cada unidad del arreglo wini, a fin de forzar la 
inicialización en el siguiente acceso. 

W do close (línea 10828) tiene muy poco que hacer en el caso de un disco duro convenció nal. 
Cuando se agrega apoyo de CD ROM u otros dispositivos removibles, esta rutina tiene que extenderse 
para generar un comando que suelte el seguro de la puerta o expulse el CD, dependien do de lo que el 
hardware maneje. 

Se invoca comsimple para emitir comandos del controlador en hardware que obligan a una 
terminación inmediata sin una fase de transferencia de datos. Los comandos que caen en esta catego ría 
incluyen los que obtienen la identificación del disco, establecen algunos parámetros y recalibran. 

Cuando com out invoca la tarea de reloj como preparación para un posible rescate después de un 
fallo del controlador en hardware del disco, pasa la dirección de wtimeout (línea 10858) 
como fúnción que la tarea del reloj debe despertar cuando expire el periodo de espera. Por lo regular, 
el disco completa la operación solicitada y, al vencerse el tiempo de espera, se observa que 
w command tiene el valor CMD IDLE, lo que implica que el disco completó su operación, 
y w timeout ya puede terminar. Si el comando no se lleva a cabo y la operación es una lectura o 
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escritura, puede ser útil reducir el tamaño de las peticiones 4e E/S. Esto se hace en dos pasos, reduciendo 
primero a 8 el número máximo de sectores que es posible solicitar, y luego a 1. Siempre que se vence un 
tiempo de espera, se exhibe un mensaje, se invoca wneedreset para forzar la reinicialización de todas las 
unidades en el siguiente intento de acceso, y se invoca interrupt para enviar un mensaje a la tarea de disco 
y simular la interrupción generada por hardware que debió haber ocurrido al término de la operación de 
disco. 


Cuando se requiere un restablecimiento, se invoca w reset (línea 10889). Esta función utiliza una 
fúnción provista por el controlador del reloj, milli-delay. Después de un retraso inicial para dar a la unidad 
de disco tiempo de recuperarse de operaciones anteriores, se parpadea un bit del registro de control del 
controlador en hardware del disco; es decir, se lleva a un nivel 1 lógico durante un periodo definido y 
luego se regresa al nivel O lógico. Después de esta operación, se invoca waitfor para dar a la unidad un 
tiempo razonable para indicar mediante una señal que está lista. Si el restablecimiento no tiene éxito, se 
exhibe un mensaje y se devuelve un estado de error. Corresponde al invocador decidir qué se hará 
después. 

Los comandos al disco que implican transferencia de datos normalmente terminan generando una 
interrupción, que envía un mensaje de vuelta a la tarea de disco. De hecho, se genera una interrupción por 
cada sector leído o escrito. Así, depués de emitirse un comando de este tipo, siempre se invoca 
w intr wait (línea 10925). A su vez, wintrwait invoca receive en un ciclo, ignorando el contenido de 
cada mensaje, esperando una interrupción que asigne a wstatus el estado de “ocioso”. Una vez recibido 
tal mensaje, se verifica el estado de la petición. Ésta es otra sección crítica, así que se usan lock y unlock 
para garantizar que no ocurrirá una nueva interrup ción que modifique w status antes de que se lleven a 
cabo los diversos pasos requeridos. 

Hemos visto varios lugares en los que se invoca la macro wai para realizar espera activa hasta que 
cambia un bit en el registro de estado del controlador en hardware del disco. Después de la prueba inicial, 
la macro waitfor invoca w wai (línea 10955), que invoca milli start para iniciar un temporizador y luego 
ingresar en un ciclo que alternadamente verifica el registro de estado y el tempo rizador. Si se vence un 
tiempo de espera, se invoca w need reset a fin de preparar las cosas para un restableci mi ento del 
controlador en hardware del disco la próxima vez que se soliciten sus servicios. 

El parámetro TIMEOUT utilizado por w waitfor se define en la línea 10206 como 32 según dos. Un 
parámetro similar, WAKEUP (línea 10193) empleado para planificar las acciones de despertar de la tarea 
de reloj, se ajusta a 31 segundos. Éstos son períodos muy largos para permanecer en espera activa, si 
consideramos que un proceso ordinario sólo recibe una tajada de tiempo de 100 ms para ejecutarse antes 
de ser expulsado. Sin embargo, estos números se basan en la norma publicada para conectar dispositivos 
de disco a computadoras de clase AT, que indica que se deben contemplar hasta 31 segundos para que un 
disco se acelere hasta adquirir la veloci dad correcta. Desde luego, esta especificación contempla el peor 
caso, y además en la mayor parte de los sistemas el disco sólo se acelera cuando la computadora se 
enciende o después de periodos largos de inactividad. MINIX todavía se está desarrollando. Es posible 
que se requiera una nueva forma de manejar los tiempos de espera cuando se agregue apoyo para 
CD ROM (u otros dispositivos que deben acelerarse con frecuencia). 

W handler (línea 10976) es el manejador de interrupciones. W identify coloca la dirección 
de esta función en la tabla de descriptores de interrupciones cuando se activa inicialmente la tarea 
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del disco duro. Cuando ocurre una interrupción de disco, el registro de estado del controlador en hardware 
del disco se copia en w status y luego se invoca la función interrupt del kemel para replanificar la tarea 
del disco duro. Claro que cuando esto ocurre la tarea del disco duro ya está bloqueada como consecuencia 
de una llamada previa a receive efectuada por w intr wait después del inicio de una operación de disco. 

La última función de at wini. c es w_ geometry, la cual devuelve los valores lógicos máximos de 
cilindro, cabeza y sector del dispositivo de disco duro seleccionado. En este caso los números son reales, 
no inventados como en el caso del controlador de disco en RAM. 


3.7.5 Manejo de discos flexibles 

El controlador en software del disco flexible es más largo y complicado que el del disco duro. Esto podría 
parecer paradójico, pues podríamos pensar que los mecanismos de disco flexible son más sencillos que los 
de disco duro. Sin embargo, al ser más sencillo el mecanismo su controla dor en hardware también es más 
simple y requiere más atención por parte del sistema operativo. Además, el hecho de que el medio es 
removible agrega ciertas complicaciones. En esta sección describiremos algunas de las cosas que un 
implementador debe considerar al manejar discos flexibles, pero no entraremos en los detalles del código 
del controlador de disco flexible en MINIX. Las partes más importantes son similares a las del disco duro. 

Una de las cosas por las que no necesitamos preocupamos en el caso del controlador en software de 
disco flexible son los múltiples tipos de controladores en hardware que tuvimos que apoyar en el caso del 
controlador de disco duro. Aunque los discos flexibles de alta densidad que se usan actualmente no se 
contemplaban cuando se diseñó la IBM PC original, los controladores en hardware de disco flexible de 
todas las computadoras de la familia IBM PC son apoyados por un solo controlador en software. El 
contraste con la situación del disco duro probablemente se debe a la falta de presión por aumentar el 
rendimiento de los discos flexibles. Los disquetes casi nunca se usan como almacenamiento de trabajo 
durante la operación de un sistema de computa dora; su rapidez y capacidad de datos son demasiado 
limitadas en comparación con las de los discos duros. Los discos flexibles siguen siendo importantes para 
la distribución de software nuevo y para respaldo, y por ello casi todos los sistemas de computadora 
pequeños están equipa dos con, por lo menos, una unidad de disco flexible. 

El controlador en software de disco flexible no usa SSF ni el algoritmo del elevador; es estrictamente 
secuencial. El controlador acepta una petición y la ejecuta antes de siquiera aceptar otra petición. Al 
diseñar originalmente MINIX se pensó que, como el sistema operativo estaba destinado a usarse en 
computadoras personales, la mayor parte del tiempo sólo habría un proceso activo, y la posibilidad de que 
llegara otra petición de disco mientras se estaba ejecutando una era pequeña. Por tanto, no se justificaba el 
considerable aumento en la complejidad del software que se requeriría para poner en cola las peticiones. 
Hoy día tal aumento es menos justificable aún, pues los discos flexibles raras veces se usan para otra cosa 
que no sea la transferencia de datos desde o hacia un sistema provisto con un disco duro. 

Habiendo dicho esto, a pesar de que el controlador en software no ofrece apoyo para 
reordenar las peticiones, el controlador de disquete, como cualquier otro controlador por bloques, puede 
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atender una petición de E/S dispersa y, al igual que el Qontrolador de disco duro, acumula las peticiones 
en un arreglo y las seguirá acumulando en tanto se sigan solicitando sectores secuenciales. Sin embargo, 
en el caso del controlador de disquete el arreglo de peticiones es más pequeño que para el disco duro, y 
está limitado al número máximo de sectores por pista de un disquete. Además, el controlador de disquete 
examina la bandera OPTIONAL en las peticiones de E/S dispersa y no procede a una nueva pista si todas 
las peticiones vigentes son opcionales. 

La sencillez del hardware del disco flexible es la causa de algunas de las complicaciones del 
controlador en software del disquete. Las unidades de disquete económicas, lentas y de baja capacidad no 
justifican los complejos controladores en hardware integrados que forman parte de las unidades de disco 
duro modernas, así que el controlador en software debe manejar explícita mente aspectos del 
funcionamiento del disco que están ocultos durante la operación de un disco duro. Como ejemplo de 
complicación causada por la sencillez de las unidades de disquete, conside remos la colocación de la 
cabeza de lectura/escritura sobre una pista específica durante una opera ción SEEK (de búsqueda). Ningún 
disco duro exige al controlador en software invocar especí ficamente SEEK. En el caso de un disco duro, 
la geometría de cilindro, cabeza y sector visible para el programador podría no corresponder a la 
geometría física y, de hecho, es posible que la geometría física sea muy complicada, con más sectores en 
los cilindros exteriores que en los interiores. Sin embargo, el usuario no percibe esto. Los discos duros 
pueden aceptar direccionamiento por bloques lógicos (LBA), usando el número de sector absoluto del 
disco, como alternativa al direccionamiento por cilindro, cabeza y sector. Incluso si el direccionamiento se 
efectúa por cilindro, cabeza y sector, se puede usar cualquier geometría que no haga referencia a sectores 
inexistentes, ya que el controla dor en hardware integrado al disco calcula la posición a la que deben 
moverse las cabezas de lectura! escritura y realiza una operación de búsqueda si es necesario. 

En cambio, en el caso de un disco flexible, es necesario programar explícitamente las opera ciones 
SEEK. En caso de fallar un SEEK, es preciso contar con una rutina que realice una operación 
RECALIBRATE que obligue a las cabezas a colocarse en el cilindro O. Esto permite al controlador en 
hardware llevarlas a una posición de pista deseada avanzando las cabezas cierto número de pasos. Desde 
luego, se requieren operaciones similares para el disco duro, pero el controlador en hardware de la unidad 
se encarga de ellas sin que el controlador en software tenga que guiarlo detalladamente. 

Entre las características de las unidades de disco flexible que hacen que su controlador en software 
sea complicado están: 

1. Medios removibles. 

2. Múltiples formatos de disco. 

3. Control del motor. 

Algunos controladores en hardware de disco duro contemplan medios removibles (por ejem pío, en 
una unidad de CD-ROM), pero en general el controlador en hardware de la unidad puede 
manejar cualquier complicación sin mucho apoyo por parte del controlador en software del 
dispositivo. En el caso del disco flexible, en cambio, el apoyo integrado no existe, a pesar de 
que se le necesita aún más. Algunos de los usos más comunes de los discos flexibles —instalar software 
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nuevo o respaldar archivos— suelen requerir el cambk de un disco a otro en la unidad. Puede haber 
problemas graves si los datos que debían ir en un disquete se escriben en otro. El controla dor en software 
de la unidad debe hacer todo lo que pueda para evitar esto, pero en muchos casos no es posible hacer 
mucho, ya que el hardware no permite determinar si la puerta de la unidad se abrió o no desde el último 
acceso. Otro problema con los medios removibles es que el sistema puede paralizarse si intenta acceder a 
una unidad de disco flexible que actualmente no tiene un disquete insertado. Esto puede resolverse si es 
posible detectar que la puerta está abierta, pero como éste no siempre es el caso, es necesario tomar 
medidas para detectar la expiración de un tiempo de espera y devolver un error si una operación de 
disquete no ter mi na en un tiempo razonable. 

Los medios removibles pueden ser sustituidos por otros medios, y en el caso de los discos flexibles 
pueden tener muchos formatos distintos. El hardware en que se usa MINIX reconoce unidades de disco 
tanto de 3.5 pulgadas como de 5.25 pulgadas, y los disquetes pueden formatearse de diversas maneras para 
contener desde 360 KB hasta 1.2 MB (en un disquete de 5.25 pulgadas) o 1.44 MB (en un disquete de 3.5 
pulgadas). MINIX reconoce siete formatos de disco flexible diferentes. Hay dos posibles soluciones al 
problema que esto causa, y MINIX contempla ambas. Una forma es referirse a cada posible formato como 
una unidad distinta y proveer múltiples dispositivos secundarios. MINIX hace esto, y en el directorio de 
dispositivos encontramos defini ciones de 14 dispositivos distintos que van desde /dev/pcO, un disquete de 
5.25 pulgadas de 360K en la primera unidad hasta ¡dey/PSi, un disquete de 3.5 pulgadas de 1 .44M en la 
segunda unidad. No es fácil recordar las diferentes combinaciones y, por ello, se ofrece una alternativa. 
Cuando nos referimos a la primera unidad de disco flexible como /dev/fdO, o a la segunda como /dev/fdl, 
el controlador en software prueba el disquete que está actualmente en la unidad cuando se accede a él, a 
fin de determinar el formato. Algunos formatos tienen más cilindros, y otros tienen más sectores por pista 
que otros formatos. La determinación del formato de un disquete se efectúa intentando leer los sectores y 
pistas con los números más altos. Un proceso de eliminación permite determinar el formato. Desde luego, 
esto toma tiempo, y cabe la posibilidad de identificar erróneamente un disquete que tiene sectores 
defectuosos. 

La última complicación del controlador en software para disco flexible consiste en el control del 
motor. No es posible leer disquetes o escribir en ellos si no están girando. Los discos duros están 
diseñados para fúncionar durante miles de horas sin desgastarse, pero si mantenemos en operación los 
motores todo el tiempo la unidad de disquete y el disquete se desgastan rápidamen. te. Si el motor no está 
encendido ya cuando se accede a una unidad, es necesario emitir un comando que arranque la unidad y 
esperar cerca de medio segundo antes de intentar leer o escribir datos. El encendido o apagado del motor 
es lento, así que MINIX deja el motor de la unidad encendido durante varios segundos después de que se 
usa una unidad. Si la unidad se usa otra vez dentro de este intervalo, el temporizador se extiende otros 
segundos más. Si la unidad no se utiliza en dicho intervalo, el motor se apaga. 


3.8 RELOJES 

Los relojes (también llamados temporizadores) son esenciales para el fúncionamiento de 
cualquier sistema de tiempo compartido por diversas razones. Entre otras cosas, los relojes mantienen la 
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hora del día y evitan que un proceso monopolice la CPU. El software del reloj puede adoptar la forma de 
un controlador de dispositivo, aunque el reloj no es un dispositivo por bloques, como un disco, ni por 
caracteres, como una terminal. Nuestro estudio de los relojes seguirá el mismo patrón que en las secciones 
anteriores: primero examinaremos el hardware y el software de reloj en general, y luego estudiaremos de 
cerca la fonna en que tales ideas se aplican a MINIX. 

3.8.1 Hardware de reloj 

Se usan comúnmente dos tipos de relojes en las computadoras, y ambos son muy diferentes de los relojes 
que la gente usa. Los relojes más sencillos están conectados a la línea de potencia de 1100 220 volts, y 
causan una interrupción a cada ciclo de voltaje, a 50 o 60 Hz. 

La otra clase de reloj consta d tres componentes: un oscilador de cristal, un contador y un registro de 
retención, como se aprecia en la Fig. 3-23. Si un cristal de cuarzo se corta correcta- mente y se monta 
sometido a tensión, puede generar una señal periódica de gran exactitud, por lo regular en el intervalo de 5 
a 100 MHz dependiendo del cristal elegido. Toda computadora incluye al menos un circuito de este tipo, 
el cual proporciona una señal de sincronización a los diferentes circuitos de la computadora. Esta señal se 
alimenta al contador para hacer que realice una cuenta regresiva. Cuando el contador llega a cero, causa 
una interrupción de la CPU. 


Oscilador de cristal 


—101 

II Mili 


llllllll 


mi.. 


El contador se decremeota en cada pulso 


Se usa un registro de retención para cargar el contador 


Figura 3-23. Reloj programable. 


Los relojes programables suelen tener varios modos de operación. En el modo de una acción, cuando 
se inicia el reloj, éste copia el valor del registro de retención en el contador y luego decrementa el 
contador en cada pulso del cristal, Cuando el contador llega a cero, causa una interrupción y se detiene 
hasta que el software lo inicia otra vez explícitamente. En el modo de onda cuadrada, después de que el 
contador llega a cero y causa la interrupción, el registro de retención se copia en el contador y todo el 
proceso se repite indefinidamente. Estas interrupciones periódicas se denominan fies de reloj. 

La ventaja del reloj programable es que su frecuencia de interrupción puede controlarse 
por software. Si se emplea un cristal de 1 MHz, el contador cambiará cada microsegundo. Si 
los registros son de 16 bits, podremos programar interrupciones que ocurran a intervalos 
desde 1 microsegundo hasta 65.536 ms. Los chips de reloj programable generalmente contienen dos o tres 
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relojes independientemente programables, además de muchas otras opciones (p. ej., contar hacia arriba en 
lugar de hacia abajo, interrupciones inhabilitadas, etcétera). 

A fin de evitar que la hora actual se pierda cuando la computadora se apaga, la mayor parte de las 
computadoras tienen un reloj de respaldo de baterías, implementado con los tipos de circuitos de baja 
potencia empleados en los relojes de pulsera digitales. El reloj de baterías puede leerse en el momento del 
arranque. Si no hay reloj de respaldo presente, el software podría preguntar al usuario la hora y la fecha 
actuales. También hay un protocolo estándar para que un sistema conectado a una red obtenga la hora 
actual de un anfitrión remoto. En cualquier caso, la hora se traduce al número de fies de reloj transcurridos 
desde las 12 A.M., Tiempo Universal Coordina do (UTC) (antes conocido como hora del meridiano de 
Greenwich) del lo. de enero de 1970, como hacen UNIX y MINIX, o a partir de otra hora de referencia. 
En cada tic del reloj, el tiempo real se incrementa en uno. Por lo regular se cuenta con prqgramas de 
utilería para establecer manualmente el reloj del sistema y el reloj de respaldo y para sincronizar los dos 
relojes. 


3,8.2 Software de reloj 

Todo lo que el hardware de reloj hace es generar interrupciones a intervalos conocidos. Todo lo demás 
relacionado con el tiempo corre por cuenta del software, el controlador del reloj. Las obligaciones exactas 
del controlador del reloj varían de un sistema operativo a otro, pero casi siempre incluyen las siguientes: 

1. Mantener la hora del día. 

2. Evitar que los procesos se ejecuten duratite más tiempo del debido. 

3. Contabilizar la utilización de la CPU. 

4. Manejar la llamada al sistema ALARM emitida por procesos de usuario. 

5. Proveer temporizadores de vigilancia a partes del sistema mismo. 

6. Preparar perfiles, vigilar y recabar datos estadísticos. 

La primera función del reloj, mantener la hora del día (también llamada tiempo real) no es difícil; 
sólo requiere incrementar un contador en cada tic del reloj, como se mencionó antes. Lo único que debe 
cuidarse es el número de bits que tiene el contador de la hora del día. Con una tasa de reloj de 60 Hz, un 
contador de 32 bits se desbordará en poco más de dos años. Es evidente que el sistema no puede 
almacenar en 32 bits el tiempo real como el número de fies transcurridos desde el I o de enero de 1970. 

Se pueden adoptar tres estrategias para resolver este problema. La primera consiste en 
usar un contador de 64 bits, aunque esto hace que el manteni mi ento del contador sea más 
costoso, pues tiene que modificarse muchas veces cada segundo. La segunda forma consiste en mantener 
la hora del día en segundos, utilizando un contador subsidiario para contar fies hasta acumular un 
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segundo completo. Dado que 232 segundos es más de 136 años, este método funcionará hasta bien entrado 
el siglo xx 

La tercera estrategia es contar en tics, pero hacerlo relativo al momento en que se arrancó el sistema, 
no a un momento externo fijo. Cuando se lee el reloj de respaldo o el usuario introduce el tiempo real, se 
calcula el momento de arranque del sistema a partir del valor de hora del día actual y se almacena en la 
memoria en cualquier forma conveniente. Más adelante, cuando se solicite la hora del día, la hora 
almacenada se sumará al contador para obtener la hora del día vigente. Estos tres enfoques se muestran en 
la Fig. 3-24. 


Hora del día en lies 


(a) 


|—38 bits—- 

i=7=i 

Hora del día Número de tics 
en segundos en el segundo actual 


32 bits - 1 
[Contador en lies] 


(b) 


Tiempo de arranque 
del sistema en segundos 
(c) 


Figura 3-24. Tres formas de mantener la hora del día. 


La segunda función del reloj es evitar que los procesos se ejecuten durante demasiado tiempo. Cada 
vez que se inicia un proceso, el planificador debe inicializar un contador con el valor del cuanto de ese 
proceso expresado en tics del reloj. En cada interrupción del reloj, el controlador del reloj decrementará el 
contador de cuanto en 1. Cuando el contador llegue a cero, el controlador del reloj llamará al planificador 
para que ponga en marcha otro proceso. 

La tercera función del reloj es contabilizar el uso de la CPU. La forma más exacta de hacer esto es 
iniciar un segundo temporizador, distinto del temporizador principal del sistema, cada vez que se inicia un 
proceso. Cuando se detiene ese proceso, se puede leer el temporizador para determinar durante cuánto 
tiempo se ejecutó el proceso. Para hacer bien las cosas, el segundo temporizador debe guardarse cada vez 
que ocurre una interrupción, y restabiecerse después. 

Una forma menos exacta, pero mucho más sencilla de llevar la contabilidad es mantener en una 
variable global un apuntador a la entrada de la tabla de procesos correspondiente al proceso que se está 
ejecutando. En cada tic del reloj, se incrementa un campo de la entrada del proceso en curso. De esta 
forma, cada tic del reloj se “cobra” al proceso que se estaba ejecutando en el momento del tic, Un 
problema menor de esta estrategia es que si ocurren muchas interrupciones durante la ejecución de un 
proceso, de todos modos se le cobrará un tic completo, aunque no haya podido realizar mucho trabajo. La 
contabilización correcta de la CPU durante las interrupcio nes es muy costosa y nunca se efectiía. 

En MINIX y muchos otros sistemas, un proceso puede solicitar que el sistema operativo le envíe un 
aviso después de cierto intervalo. El aviso casi siempre es una señal, interrupción, mensaje o algo similar. 
Una aplicación que requiere tales avisos es el trabajo en redes, en el que un paquete del cual no se ha 
acusado recibo dentro de cierto intervalo de tiempo debe retransmitirse. 
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Otra aplicación es la enseñanza asistida por computadora donde, si un estudiante no proporciona la 
respuesta dentro de cierto tiempo, recibe la respuesta del programa. 

Si el controlador de reloj tuviera suficientes relojes, podría establecer un reloj individual para cada 
petición. Como no sucede así, es preciso simular varios relojes virtuales con un solo reloj físico. Una 
forma de hacerlo es mantener una tabla en la que se guarda el tiempo de señal para todos los 
temporizadores pendientes, además de una variable que indica el tiempo del siguiente. Cada vez que se 
actualiza la hora del día, el controlador determina si ya ocurrió la señal más cercana. Si así fue, se busca 
en la tabla la siguiente señal que ocurrirá. 

Si se esperan muchas señales, resulta más eficiente simular múltiples relojes encadenando todas las 
peticiones de reloj pendientes, ordenadas por tiempo, en una lista enlazada, como se muestra en la Fig. 3- 
25. Cada entrada de la lista indica cuántos tics del reloj hay que esperar después de la anterior antes de 
causar una señal. En este ejemplo, hay señales pendientes para 4203, 4207, 4213, 4215 y 4216. 


Hofa actual Sigu iente señal 


I «a» I H 


Cabecera 
de reloj 



Figura 3-25. Simulación de múltiples temporizadores con un solo reloj. 


En la Fig. 3-25, la siguiente interrupción ocurrirá en 3 tics. En cada tic, se decrementa Si guíente 
señal. Cuando ésta llega a cero, se causa la señal correspondiente al primer elemento de la lista, y dicho 
elemento se elimina de la lista. A continuación se asigna a Siguiente señal el valor de la entrada que ahora 
está a la cabeza de la lista, que en este ejemplo es 4 

Observe que durante una interrupción de reloj el controlador de reloj tiene varias cosas que hacer: 
incrementar el tiempo real, decrementar el cuanto y verificar si es 0, realizar la contabiliza ción de la CPU 
y decrementar el contador de la alarma. No obstante, cada una de estas operacio nes se ha dispuesto 
cuidadosamente de modo que sea muy rápida, ya que deben repetirse muchas veces cada segundo. 

Algunas partes del sistema operativo también necesitan establecer temporizadores llamados 
temporizadores de vigilancia. Al estudiar el controlador del disco duro vimos que se planifica una llamada 
de despertar cada vez que se envía un comando al controlador en hardware del disco, de modo que pueda 
intentarse la recuperación si el comando falta por completo. También mencio namos que los controladores 
en software de disco flexible deben esperar hasta que el motor del disco adquiere la velocidad correcta, y 
deben apagar el motor si no ocurre actividad durante cierto tiempo. Algunas impresoras provistas de 
cabeza de impresión móvil pueden imprimir 120 carac teres por segundo (8.3 ms/carácter), pero no 
pueden regresar la cabeza de impresión al margen izquierdo en 8.3 ms, así que el controlador de la 
terminal debe esperar después de que se teclea un retomo de carro. 

El mecanismo empleado por el controlador del reloj para manejar los temporizadores de 
vigilancia es el mismo que se emplea para las señales de usuario. La única diferencia es que cuando un 
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temporizador termina, el controlador del reloj, en lugar de causar una señal, invoca un procedimiento 
proporcionado por el invocador. El procedimiento forma parte del código del invocador, pero dado que 
todos los controladores están en el mismo espacio de direcciones, el controlador del reloj también puede 
invocarlo. El procedimiento invocado puede hacer todo lo necesario, incluso causar una interrupción, 
aunque dentro del kemel las interrupciones no suelen ser recomendables y las señales no existen. Es por 
esto que se proporciona el mecanismo de vigilancia. 

El último elemento de nuestra lista es la preparación de perfiles. Algunos sistemas operativos 
cuentan con un mecanismo mediante el cual un programa de usuario puede hacer que el sistema prepare 
un histograma de su contador de programa, a fin de ver a qué está dedicando su tiempo.Cuando se van a 
preparar perfiles, el controlador verifica en cada tic si se está preparando un perfil del proceso actual y, de 
ser así, calcula el número de gaveta (un intervalo de direcciones) correspondiente al contador de programa 
actual. A continuación, el controlador incrementa esa gaveta en uno. Este mecanismo también puede 
servir para preparar perfiles del sistema mismo. 


3.8.3 Generalidades del controlador de reloj en MINIX 

El controlador de reloj de MINIX está contenido en el archivo clock.c. La tarea de reloj acepta estos sE/S 
tipos de mensajes, con los parámetros que se indican: 

1. HARDINT 

2. GET UPTIME 

3. GETTIME 

4. SETTIME (nuevo tiempo en segundos) 

5. SETALARM (número de proceso, procedimiento por invocar, retraso) 

6. SET SYN AL (número de proceso, retraso) 

HARD INT es el mensaje que se envía al controlador cuando ocurre una interrupción de reloj y hay 
trabajo que realizar, como cuando debe enviarse una alarma o un proceso se ha ejecutado durante 
demasiado tiempo. 

GETUP TIME sirve para obtener el tiempo en fies desde el momento del arranque. GET TIME 
devuelve el tiempo real actual como el número de segundos transcurridos desde el lo. de enero de 1970 a 
las 12 A.M., y SETTIME fija el tiempo real. Este mensaje sólo puede ser enviado por el Superusuario. 

Dentro del controlador del reloj, se lleva el tiempo usando el método de la Fig. 3-24(c). Cuando se 
fija la hora, el controlador calcula el tiempo desde el arranque del sistema. El controla dor puede efectuar 
este cálculo porque tiene el tiempo real actual y sabe durante cuántos fies el sistema ha estado 
fúncionando. El sistema almacena el tiempo real del arranque en una variable. Después, cuando se invoca 
GET TIME, el sistema convierte el valor actual del contador de fies a segundos y lo suma al tiempo desde 
el arranque que tiene almacenado. 

SET ALARM permite a un proceso establecer un temporizador que “suena” en cierto 
número de fies del reloj. Cuando un proceso de usuario realiza una llamada ALARM, envía un mensaje al 
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administrador de memoria, el cual a su vez envía ese mensaje al controlador de reloj. Cuando la alarma 
“suena”, el controlador del reloj envía un mensaje de vuelta al administrador de memoria, que entonces se 
encarga de que se envíe la señal. 

SET A LARM también es utilizado por tareas que necesitan iniciar un temporizador de vigi lancia. 
Cuando el temporizador se vence, simplemente se invoca el procedimiento proporcionado. El controlador 
del reloj no tiene idea de qué hace el procedimiento. 

SET SYN AL es similar a SET ALARM, pero se usa para establecer una alarma síncrona. Una 
alarma síncrona envía un mensaje a un proceso, en lugar de generar una señal o invocar un procedimiento. 
La tarea de alarma síncrona se encarga de enviar mensajes a los procesos que los requieren. Veremos las 
alarmas síncronas con mayor detalle posteriormente. 

La tarea de reloj no utiliza estructuras de datos importantes, pero se emplean algunas varia bles para 
llevar el tiempo. Sólo una de ellas es una variable global, lostticks, definida en glo.h (línea 5031). Se 
incluye esta variable para que la use cualquier controlador que pudiera agregarse a MINIX en el futuro y 
que pudiera inhabilitar las interrupciones durante un tiempo tan largo que pudieran perderse uno o más 
fies del reloj. Por ahora no se emplea esta variable, pero si se escribiera un controlador semejante el 
programador podría hacer que se incremente lost ticks para compensar el tiempo durante el cual se 
inhibieron las interrupciones de reloj. 

Obviamente, las interrupciones de reloj ocurren con mucha frecuencia, y es importante ma nejarlas 
rápidamente. MINIX logra esto realizando el mínimo de procesamiento en la mayor parte de las 
interrupciones de reloj. Al recibir una interrupción, el manejador asigna el valor de lost ticks + 1 a una 
variable local, ticks, y luego usa esta cantidad para actualizar los tiempos de contabiliza ción y 
pending licks (línea 11079); además, vuelve a poner lost ticks en cero. Pendingticks (fies pendientes) es 
una variable PRI VATE, declarada fuera de todas las definiciones de funciones pero conocida sólo para 
las funciones definidas en clock.c. Otra variable PRIVA TE, sched ticks, se decrementa en cada tic para 
llevar un registro del tiempo de ejecución. El manejador de inte rrupciones envía un mensaje a la tarea del 
reloj sólo si se vence una alarma o si se acaba un cuanto de ejecución. Este esquema permite que el 
manejador de interrupciones regrese casi de inmediato en la mayor parte de las interrupciones. 

Cuando la tarea del reloj recibe un mensaje, suma pending ticks a la variable realtime (línea 11067) 
y luego pone en ceros pending ticks. Realtime, junto con la variable boottime (línea 11068) permite 
calcular la hora del día actual. Las dos son variables PR! VA TE, así que la única forma que tiene 
cualquier otra parte del sistema de obtener la hora es enviando un mensaje a la tarea del reloj. Aunque en 
un instante dado realtime puede ser inexacta, este mecanismo asegura que siempre será exacta cuando se 
necesite. Si nuestro reloj de pulsera marca la hora correcta cuando lo miramos, ¿qué importa si no marca 
la hora correcta cuando no lo estamos viendo? 

Para manejar las alarmas, next_alar,n registra el tiempo en el que la siguiente señal o llamada de 
vigilancia puede ocurrir. El controlador debe tener cuidado aquí, porque el proceso que solicita la señal 
podría llegar a su fin o ser terminado antes de que la señal suceda. Cuando llega el momento de la señal, 
se verifica si todavía se necesita. Si no se necesita, no se genera. 

Un proceso de usuario sólo puede tener un temporizador de alarma vigente. La ejecución 
de una llamada ALARM mientras el temporizador está corriendo cancela el primer temporizador. 
Por tanto, una forma cómoda de almacenar 1 os temporizadores consiste en reservar una palabra en la 
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entrada de tabla de procesos de cada proceso para su temporizados si existe. En el caso de las tareas, 
también debe almacenarse en algún lado la función que se invocará, y para este fin se cuenta con el 
arreglo watch dog. Un arreglo similar, syn table, almacena banderas que indican, para cada proceso, si va 
a recibir o no una alarma síncrona. 

La lógica global del controlador del reloj sigue el mismo patrón que los controladores de disco. El 
programa principal es un ciclo infinito que obtiene mensajes, realiza acciones dependien do del tipo de 
mensajes, y luego envía una respuesta (excepto en el caso de CLOCK TICK). Cada tipo de mensaje se 
maneja con un procedimiento distinto, siguiendo nuestra convención estándar de nombrar doxxx a todos 
los procedimientos invocados desde el ciclo principal, donde xxx es diferente para cada procedimiento. 
Como acotación, resulta desafortunado que muchos enlazadores truncan los nombres de procedimiento a 
siete u ocho caracteres, así que los nombres dosettime y dosetalarm podrían causar conflictos. Por ello 
se cambió el nombre del segundo procedí miento a do setalarm. Este problema ocurre en todo MINIX y, 
por lo regular, se resuelve abrevian do uno de los nombres. 


La tarea de alarma síncrona 

Hay una segunda tarea que debemos estudiar en esta sección, la tarea de alarma síncrona. Una alarma 
síncrona es similar a una alarma normal, pero en vez de enviar una señal o invocar una función vigilante 
cuando expira el periodo de espera, la tarea de alarma síncrona envía un mensaje. Podría llegar una señal 
o podría invocarse una tarea vigilante sin importar qué parte de la tarea se está ejecutando, así que las 
alarmas de estos tipos son asincronas. En contraste un mensaje sólo se recibe cuando el receptor ha 
ejecutado una llamada receive. 

El mecanismo de alarma síncrona se agregó a MINIX a fin de apoyar el servidor de red que, al igual 
que el administrador de memoria y el servidor de archivos, se ejecuta como proceso indivi dual. Es 
frecuente que surja la necesidad de poner un límite al tiempo que un proceso puede bloquearse mientras 
espera entradas. Por ejemplo, en una red, si no se recibe un acuse de recibo de un paquete de datos dentro 
de un periodo definido, es probable que haya habido una falla de transmisión. Un servidor de red puede 
establecer una alarma síncrona antes de que trate de recibir un mensaje y se bloquee. Puesto que la alarma 
síncrona se entrega como mensaje, desbloqueará el servidor tarde o temprano si éste no recibe un mensaje 
de la red. Al recibir cualquier mensaje, lo primero que el servidor debe hacer es restablecer la alarma. 
Luego, al examinar el tipo u origen del mensaje, podrá determinar si llegó un paquete o si fue 
desbloqueado porque se venció un tiempo de espera. Si sucedió lo segundo, el servidor puede intentar la 
recuperación, por lo regular volviendo a enviar el último paquete del cual no se adusó recibo. 

Una alarma síncrona es más rápida que una alarma enviada mediante una señal, lo cual requiere 
varios mensajes y una cantidad considerable de procesamiento. Una fúnción vigilante es rápida, pero sólo 
puede usarse con tareas compiladas en el mismo espacio de direcciones que la tarea del reloj. Cuando un 
proceso está esperando un mensaje, una alarma síncrona es más apropiada y sencilla que las señales o las 
funciones de vigilancia, y se puede manejar fácilmente con poco procesamiento adicional. 
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El manejador de interrupciones de reloj 

Como se explicó antes, cuando ocurre una interrupción de reloj, realtime no se actualiza de inmediato. La 
rutina de servicio de interrupciones mantiene el contador pendingticks y realiza trabajos sencillos como 
cobrar el tic actual a un proceso y decrementar el temporizador de cuantos. Se envía un mensaje a la tarea 
del reloj sólo cuando es preciso realizar actividades más complicadas. Aunque lo ideal es que todas las 
tareas de MINIX se comuniquen mediante mensajes, esto es una concesión práctica ante la realidad de que 
dar servicio a los tics de reloj consume tiempo de CPU. En una máquina lenta se observó que al hacerse 
las cosas de esta manera se lograba un aumento del 15% en la rapidez del sistema relativa a una 
implementación que enviaba un mensaje a la tarea del reloj en cada interrupción del reloj. 


Temporización de milisegundos 

Como concesión adicional a la realidad, se incluyen unas cuantas rutinas en clock. c que ofrecen 
temporización con definición de milisegundos. Varios dispositivos de E/S requieren retrasos muy cortos 
(hasta 1 ms). No existe una forma práctica de implementar esto usando alarmas y la interfaz de 
transferencia de mensajes. Estas funciones están diseñadas para ser invocadas directamente por las tareas. 
La técnica empleada es la técnica de E/S más antigua y sencilla: la encuesta o interrogación. El contador 
que se emplea para generar las interrupciones de reloj se lee directamente, con la mayor rapidez posible, y 
la cuenta se convierte a milisegundos. El invocador hace esto repetidamente hasta que transcurre el tiempo 
deseado. 


Resumen de los servicios de reloj 

En la Fig. 3-26 se resumen los diversos servicios provistos por clock.c. Hay varias formas de acceder al 
reloj, y también de atender la petición. Algunos servicios están disponibles para cualquier proceso, y los 
resultados se devuelven en un mensaje. 

El tiempo desde el arranque (uptime) se puede obtener mediante una llamada de función desde el 
kemel o una tarea, evitando el gasto extra de un mensaje. Una alarma puede ser solicitada por un proceso 
de usuario, en cuyo caso el resultado final es üna señal, o por una tarea, causando la activación de una 
función vigilante. Ninguno de estos mecanismos puede ser utilizado por un proceso servidor, pero un 
servidor puede pedir una alarma síncrona. Una tarea o el kemel puede solicitar un retraso empleando la 
función millide lay, o puede incorporar llamadas a milli elapsed en una rutina de escrutinio, por ejemplo, 
mientras espera entradas de un puerto. 


3.8.4 Implementación del controlador de reloj en MINIX 

Cuando se inicia MINIX, se invocan todos los controladores. La mayor parte de ellos sólo intenta 
obtener un mensaje y se bloquea. El controlador de reloj, clock task (línea 11098), hace lo 
mismo, pero primero invoca init clock para inicializar la frecuencia del reloj programable en 60 
Hz. Cada vez que se recibe un mensaje, el controlador suma pending ticks a realtime y luego restablece 
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Parámetro 

DI aqueta IBM de 360 KB 

Disco duro WD de 540 MB 

Número de cilindros 

40 

1048 

Pistas por cilindro 

2 

4 

Sectores por pista 

9 

252 

Sectores por disco 

720 

1056384 

Byies por sector 

512 

512 

Bytes por disco 

368640 

540868608 

Tiempo de búsqueda (cilindros adyacentes) 

6 ms 

4 ms 

Tiempo de búsqueda (caso medio) 

77 ms 

11 ms 

Tiempo de rotación 

200 ms 

13 ms 

Tiempo de arranque/paro del motor 

250 ms 

• • ' 

Tiempo para transferir un sector 

22 ms 

L . 53,18 J 


Figura 3-19. Parámetros de disco para el disqoete de 360 KB de la IBM PC original y un 
disco duro Western Digital WD AC2540 de 540 MB. 


pendingticks antes de hacer cualquier otra cosa. Esta operación podría entrar en conflicto con una 
interrupción de reloj, así que se usan llamadas a lock y unlock para evitar una competencia (líneas 11115a 
11118). Por lo demás, el ciclo principal del controlador del reloj es esencialmente igual al de los demás 
controladores: se recibe un mensaje, se invoca una función que realice el trabajo necesario, y se envía un 
mensaje de respuesta. 

Do_c (línea 11140) no se invoca en cada tic del reloj, así que su nombre no es Una descripción 
exacta de su función; se invoca cuando el manejador de interrupciones determina que podría haber algo 
importante que hacer. Primero se verifica si hubo una señal o terminó un temporizador vigilante. Si fue 
así, se inspeccionan todas las entradas de alarma en la tabla de procesos. Dado que los fies no se procesan 
individualmente, varias alarmas podrían “sonar” en una pasada por la tabla. También es posible que el 
proceso que iba a recibir la siguiente alarma ya haya terminado. Si se encuentra un proceso cuya alarma 
sea menor que el tiempo actual, pero no cero, se verifica la ranura del arreglo watchdog (vigilante) que 
corresponde a ese proceso. En el lenguaje de programación C un valor numérico también tiene un valor 
lógico, de modo que la prueba de la línea 11161 devuelve TRUE si hay una dirección válida almacenada 
en la ranura de watch dog, y la función correspondiente se invoca indirectamente en la línea 11163. Si se 
en cuentra un apuntador nulo (representado en C con un valor de cero), el resultado de la prueba es 
FALSE y se invoca causesig para enviar una señal SIGALRM. La ranura de watch dog también se usa 
cuando se necesita una alarma síncrona. En ese caso la dirección almacenada es la dirección de 
causea/am no la dirección de una función de vigilancia perteneciente a una tarea en particular. Para 
enviar una señal podríamos haber almacenado la dirección de cause sig, pero entonces tendríamos que 
haber escrito cause sig de forma diferente, sin esperar argumentos y obteniendo el número del proceso 
objetivo de una variable global. Como alternativa, podríamos haber hecho que todos los procesos 
vigilantes esperaran un argumento que no necesitan. 

Analizaremos cause sig cuando expliquemos la tarea del sistema en una sección subsecuen te. Su 
trabajo consiste en enviar un mensaje al administrador de memoria. Esto requiere verificar si el 
administrador de memoria actualmente está esperando un mensaje. Si es así, cause sig le envía un 
mensaje informándole de la alarma. Si el administrador de memoria está ocupado, cause sig toma nota de 
que debe informarle de la alarma en la primera oportunidad. 
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Mientras se recorre la tabla de procesos inspeccionando el valor de p alarm para cada proceso, se 
actualiza nextalarm. Antes de iniciar el ciclo, se asigna a nextalarm un número muy grande (línea 
11151) y luego, para cada proceso cuyo valor de alarma sea distinto de cero después de enviarse las 
alarmas o señales, se comparan la alarma del proceso y next alarm, y se asigna a éste el más pequeño de 
los dos valores (líneas 11171 y 11172). 

Después de procesar las alarmas, doclocktick determina si ya es momento de planificar otro 
proceso. El cuanto de ejecución se mantiene en la variable PRIVA TE schedticks, que normal mente es 
decrementada por el manejador de interrupciones del reloj en cada tic del reloj. Sin embargo, en los fies en 
los que se activa do clocktick, el manejador no decrementa sched ticks, pues deja que do clocktick 
mismo lo haga y pruebe si el resultado es cero en la línea 11178. Sched ticks no se restablece cada vez 
que se planifica un proceso nuevo (porque se permite que el sistema de archivos y el administrador de 
memoria se ejecuten hasta terminar). En vez de ello, se restablece después de cada SCHED RATE fies. 
La comparación de la línea 11179 se efectúa para asegurarse de que el proceso actual se ejecutó realmente 
durante, por lo menos, un tic completo del planificador antes de quitarle la CPU. 

El siguiente procedimiento, dogetuptime (línea 11189), comprende sólo una línea; coloca el valor 
actual de realtime (el número de fies transcurridos desde el arranque) en el campo correcto del mensaje 
que se devolverá. Cualquier proceso puede averiguar el tiempo transcurrido de esta manera, pero el gasto 
extra del mensaje puede ser excesivo para las tareas, así que se proporciona una función relacionada, 
getuptime (línea 11200) que puede ser invocada directamente por las tareas. Puesto que getuptime no se 
invoca mediante un mensaje a la tarea de reloj, tiene que sumar ella misma los fies pendientes al valor 
actual de realtime. Se necesitan lock y unlock aquí para evitar que ocurra una interrupción de reloj 
mientras se está accediendo a pending ticks. 

Para obtener el tiempo real vigente, dogettime (línea 11219) utiliza realtime y boottime (el 
tiempo desde el arranque del sistema en segundos). Dosettime (línea 11230) es su comple mentó; 
calcula un nuevo valor para boot time con base en el tiempo real vigente dado y el número de fies 
transcurridos desde el arranque. 

Los procedimientos dosetalarm (línea 11242) y dosetsynalrm (línea 11269), para estable cer una 
alarma normal y una alarma síncrona, respectivamente, son tan parecidos que los describí remos juntos. 
Ambos extraen del mensaje los parámetros que especifican el proceso al que se enviará una señal y el 
tiempo que debe esperarse. Do setalarm también extrae la dirección de una fúnción que se invocará (línea 
11257), aunque unas cuantas líneas más adelante sustituye este valor con un apuntador nulo si el proceso 
objetivo es un proceso de usuario y no una tarea. Ya hemos visto cómo más adelante se prueba este 
apuntador en do clocktick para determinar si el objetivo debe recibir una señal o una llamada a un 
vigilante. Ambas fúnciones calculan también el tiempo que falta para “sonar” la alarma (en segundos) y lo 
incluyen en el mensaje de retomo. Ambas invocan entonces commonsetalarm para finalizar sus 
actividades. En el caso de la llama da a do setsyn almz, el parámetro de función que se pasa a 
common setalarm siempre es causealarm, 

Common setalarm (línea 11291) termina el trabajo iniciado por cualquiera de las dos 
funciones que acabamos de describir, y luego almacena el tiempo de la alarma en la tabla de procesos 
y el apuntador al procedimiento vigilante (que también podría ser un apuntador a cause alarm o un 
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apuntador nulo) en el arreglo watchdog. A continuación, common setalarm revisa toda la tabla de 
procesos para encontrar la siguiente alarma, tal como lo hace doclocktick. 

Cause_alar,n (línea 11318) es sencilla; asigna TRUE a una entrada del arreglo syntabie que 
corresponde al objetivo de la alarma síncrona. Si la tarea de alarma síncrona no está viva, se le envía un 
mensaje para que despierte. 


Implementación de la tarea de alarma síncrona 

La tarea de alarma síncrona, synalarmtask (línea 11333), sigue el modelo básico de todas las tareas: 
inicializa y luego ingresa en un ciclo sin fin en el que recibe y envía mensajes. La inicialización consiste 
en declarar que está viva asignando TRUE a la variable syn al alive y luego declarar que no tiene nada 
que hacer asignando FALSE a todas las entradas de syn tabie. Esta tabla tiene una entrada para cada 
ranura de la tabla de procesos Syn alarin task inicia su ciclo extenor declarando que ha completado su 
trabajo y luego ingresa en un ciclo interior donde revisa todas las ranuras de syn tabie. Si encuentra una 
entrada que indique que se espera una alarma síncrona, esta tarea restablece la entrada, envía un mensaje 
del tipo CLOcK INT al proceso apropiado, y declara que no ha completado aún su trabajo. Al final de su 
ciclo exterior, la tarea no se detiene a esperar nuevos mensajes a menos que su bandera work done este en 
1 indicando que ya completo su trabajo. No se necesita un mensaje nuevo para indicarle a la tarea que hay 
más trabajo que efectuar, ya que causealarm escribe directamente en syn tabie. Sólo se necesita un 
mensaje para despertar la tarea después de que se ha quedado sin trabajo El efecto es que esta tarea repite 
su ciclo con gran rapidez en tanto hay alarmas que entregar. 

De hecho, esta tarea no se utiliza en la versión de distribución de MINIX. Sin embargo, si 
recompilamos MINIX para agregar apoyo de trabajo con redes, el servidor de red la usará, pues necesita 
exactamente este tipo de mecanismo para obligar el vencimiento rápido de tiempos de espera silos 
paquetes no se reciben en el plazo esperado. Además de que se requiere velocidad, no es posible enviar 
señales a los servidores, ya que éstos deben ejecutarse indefinidamente, y la acción por omisión de la 
mayor parte de las señales es terminar el proceso objetivo. 


Implementación del manejador de interrupciones de reloj 

El diseño del manejador de interrupciones de reloj es un término medio entre hacer muy poco 
(a fin de minimizar el tiempo de procesamiento) y hacer lo suficiente para que no sea 
necesario activar con demasiada frecuencia la tarea del reloj, lo cual resulta costoso. 
El manejador modifica unas cuantas variables y prueba otras. Lo primero que hace clockhandler 
(línea 11374) es realizar algo de contabilidad del sistema. MINIX sigue la pista tanto al tiempo 
de usuario como al tiempo de sistema. El tiempo de usuario se carga a un proceso si se 
está ejecutando cuando ocurre un tic del reloj. El tiempo de sistema se carga si se está 
ejecutando el sistema de archivos o el administrador de memoria. La variable bill_ptr siempre apunta 
al último proceso de usuario planificado (los dos servidores no cuentan). La facturación se efectúa en 
las líneas 11447 y 11448. Una vez realizada la facturación, se incrementa pending ticks, que es la variable 
más importante mantenida por clock handler (línea 11450). Es preciso conocer el tiempo real para 
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probar si clockhandler debe despertar o no la terminal o enviar un mensaje a la tarea de reloj, pero la 
actualización en sí de realtime es costosa, porque esta operación debe efectuarse usando candados. A fin 
de evitar esto, el manejador calcula su propia versión del tiempo real en la variable local now. Existe la 
posibilidad de que el resultado sea incorrecto de vez en cuando, pero las consecuencias de tal error no 
serían graves. 

El resto del trabajo del manejador depende de diversas pruebas. La terminal y la impresora deben 
despertarse cada cierto tiempo. Ttytimeout es una variable global, mantenida por la tarea de la terminal, 
que indica cuándo deberá despertarse la terminal la próxima vez. En el caso de la impresora es necesario 
verificar varias variables que son PRI VATE dentro del módulo de la im presora, y se prueban en la 
llamada a pr re start, que regresa rápidamente incluso si la impresora está paralizada, lo que sería el peor 
de los casos. En las líneas 11455 a 11458 se realiza una prueba que activa la tarea del reloj si se venció 
una alarma o si es hora de planificar otra tarea. Esta última prueba es compleja, un AND lógico de tres 
pruebas más sencillas. El código 

interrupt(CLOCK); 

de la línea 11459 hace que se envíe un mensaje HARD INT a la tarea del reloj. 

Al describir doclocktick señalamos que decrementa schedticks y prueba si es cero para detectar la 
expiración del cuanto de ejecución. Probar si sched ticks es igual a uno forma parte de la compleja prueba 
que mencionamos antes; aunque no se active la tarea del reloj, será necesario decrementar sched ticks 
dentro del manejador de interrupciones y, si llega a cero, restablecer el cuanto. Si ocurre esto, también es 
momento de indicar que el proceso actual estaba activo al iniciarse el nuevo cuanto; esto se hace 
asignando el valor actual de bill_ptr a prev_ptr en la línea 11466. 


Utilerías de tiempo 

Por último, clock.c contiene algunas funciones que proporcionan diversos apoyos. Muchas de éstas son 
específicas para el hardware y tendrán que ser reemplazadas si MINIX se traslada a hardware que no sea 
Intel. Sólo describiremos lo que hacen estas fúnciones, sin entrar en detalles de su implementación. 

Initclock (línea 11474) es invocada por la tarea del temporizador cuando se ejecuta por primera vez. 
La fúnción establece el modo y el retraso del chip temporizador de modo que produzca interrupciones de 
tic de reloj 60 veces cada segundo. A pesar del hecho de que la “velocidad de CPU” que se anuncia en la 
publicidad de las PC ha aumentado de 4.77 MHz para la IBM PC original a más de 200 MHz en los 
sistemas modernos, la constante TIMER COUNT, empleada para inicializar el temporizador, es la misma 
en todos los modelos de PC en los que se ejecuta MINIX. Toda PC compatible con IBM, sea cual sea la 
velocidad de su procesador, suminis tra una señal de 14.3 MHz que es utilizada por diversos dispositivos 
que necesitan una referencia de tiempo. Las líneas de comunicación en serie y la pantalla de video 
también necesitan esta referencia de temporización. 

El complemento de initclock es clock.stop (línea 11489). Esta función no es 
realmente necesaria, pero es una concesión al hecho de que los usuarios de MINIX podrían querer iniciar 
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otro sistema operativo de vez en cuando. Clock stop simplemente restablece los parámetros del chip 
temporizador al modo de operación predeterminado que MS-DOS y otros sistemas operativos podrían 
esperar del ROM BIOS en el momento de iniciarse. 

Se proporciona milli delay (línea 11502) para ser utilizada por cualquier tarea que necesite retrasos 
muy cortos. La función está escrita en C sin referencias a hardware específico, pero utiliza una técnica que 
sólo esperaríamos encontrar en una rutina de bajo nivel en lenguaje ensamblador. MillLdelay inicializa un 
contador en cero y luego lo encuesta rápidamente hasta que alcanza un valor deseado. En el capítulo 2 
dijimos que en general debe evitarse esta técnica de espera activa, pero las exigencias de la 
implementación pueden requerir excepciones a las reglas generales. La inicialización del contador corre 
por cuenta de la siguiente función, milli start (línea 11516), que simplemente pone en cero dos variables. 
El escrutinio se efectúa invocando la última función, milli elapsed (línea 11529), que accede al hardware 
del temporizador. El conta dor que se examina es el mismo que se utiliza para la cuenta regresiva de tics 
del reloj, y por tanto puede sufrir un desbordamiento negativo y recuperar su valor máximo antes de que 
se complete el retraso deseado. Milli realiza la corrección necesaria en tal caso. 


3.9 TERMINALES 

Todas las computadoras de propósito general tienen una o más term in ales que sirven para comunicarse 
con ellas. Hay un número muy grande de tipos de ter mi n a les distintos, y toca al controlador de la ter mi nal 
ocultar todas estas diferencias de modo que la parte del sistema operati vo independiente del dispositivo y 
los programas de usuario no tengan que reescribirse para cada tipo de terminal. En las siguientes secciones 
seguiremos nuestro enfoque estándar de examinar primero el hardware de las terminales en general y 
luego estudiar el software de MINIX. 


3.9.1 Hardware de terminales 

Desde el punto de vista del sistema operativo, las ter mi nales pueden dividirse en tres categorías amplias 
con base en la forma en que el sistema operativo se comunica con ellas. La primera categoría consiste en 
term in ales con mapa en la memoria, que consisten en un teclado y una pantalla, ambas conectadas 
directamente a la computadora. La segunda categoría consiste en ter mi n a les que se conectan a través de 
una línea de comunicación en serie empleando el estándar RS-232, casi siempre usando un módem. La 
tercera categoría consiste en ter mi nales que se conectan a la computadora a través de una red. Esta 
taxonomía se muestra en la Fig. 3-27. 


Terminales con mapa en la memoria 

La primera categoría amplia de ter mi nales indicada en la Fig. 3-27 consiste en dispositivos con mapa en la 
memoria. Estas ter mi nales son parte integral de las computadoras mismas. La interfaz con las ter mi nales 
con mapa en la memoria se establece a través de una memoria especial llamada RAM de video que forma 
parte del espacio de direcciones de la computadora y es direccionada por la CPU de la misma forma que el 
resto de la memoria (Fig. 3-28). 
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figura 3-27. Tipos de terminales 


Figura 3-27. Tipos de terminales. 

La tarjeta de RAM de video también contiene un chip llamado controlador de video. Este chip 
extrae códigos de caracteres de la RAM de video y genera la señal de video que maneja la pantalla 
(monitor). El monitor genera un haz de electrones que barre la pantalla horizontalmente, dibujando líneas 
sobre ella. Por lo regular, la pantalla contiene entre 480 y 1024 líneas horizontales, cada una de las cuales 
tiene entre 640 y 1200 puntos. Estos puntos se deno mi nan pixeles. La señal del controlador de video 
modula el haz de electrones, determinando si un pixel dado estará iluminado u oscuro. Los monitores a 
color tienen tres haces, para rojo, verde y azul, que se modulan de forma independiente. 



paralelo 

Figura 3-28. Las terminales mapeadas en memoria escriben directamente en la RAM de video. 

Una pantalla monocromática sencilla podría e xh ibir un carácter en un cuadro de 9 pixeles de 
anchura y 14 pixeles de altura (incluido el espacio entre caracteres), contando así con 25 líneas de 80 
caracteres cada una. En tal caso, la pantalla tendría 350 líneas de barrido con 720 pixeles cada una. Cada 
una de estas tramas se redibuja de 45 a 70 veces por segundo. El controlador de video podría diseñarse de 
modo que obtenga los primeros 80 caracteres de la RAM de video, genere 14 líneas de barrido, obtenga 
los siguientes 80 caracteres de la RAM de video, genere las siguientes 14 líneas de barrido, etc. De hecho, 
la mayor parte de los controladores obtienen los caracteres 14 veces, una por cada línea de barrido, para 
no tener que guardarlos en un buffer interno. 
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Los patrones de 9 x 14 bits para los caracteres se guardan en una ROM empleada por el 
controlador de video (también puede usarse RAM para manejar tipos de letra personalizados). Las 
direcciones de esta ROM tienen 12 bits, 8 bits para el código del carácter y 4 bits para especificar la línea 
de barrido. Los 8 bits de cada byte de la ROM controlan 8 pixeles; el noveno pixel entre caracteres 
siempre está en blanco. Por tanto, se necesitan 14 x 80 = 1120 referencias a la RAM de video para exhibir 
una línea de texto en la pantalla. Se hace un número igual de referencias a la ROM del generador de 
caracteres. 

La IBM PC tiene varios modos para la pantalla. En el más sencillo, se usa una pantalla con mapa 
de caracteres para la consola. En la Fig. 3-29(a) vemos una porción de la RAM de video. Cada carácter de 
la pantalla de la Fig. 3-29(b) ocupa dos caracteres de la RAM. El carácter de orden bajo es el código 
ASCII para el carácter que se exhibe. El carácter de orden alto es el byte de atributo, que sirve para 
especificar el color, video inverso, parpadeo, etc. La pantalla completa de 25 por 80 caracteres requiere 
4000 bytes de RAM de video en este modo. 


RAM de video 



- 80 caradores ' 
(b) 


Figura 3-29. (a) Imagen de RAM de video para la pantalla monocromática IBM. (b) La pantalla 
correspondiente. Las x son bytes de atributos. 

Las terminales de mapa de bits usan el mismo principio, excepto que se controla individualmente 
cada pixel de la pantalla. En la configuración más simple, para una pantalla monocromática, cada pixel 
tiene un bit correspondiente en la RAM de video. En el otro extremo, cada pixel se representa con un 
número de 24 bits, dedicando 8 bits para cada color básico: rojo, verde y azul. Una pantalla a color de 768 
x 1024 con 24 bits por pixel requiere 2 MB de RAM sólo para contener la imagen. 

Cuando se usa una pantalla con mapa en memoria, el teclado está totalmente desacoplado de la 
pantalla. La interfaz con el teclado puede ser a través de un puerto en serie o en paralelo. En cada acción 
de tecla, se interrumpe la CPU, y el controlador del teclado extrae el carácter digitado leyendo un puerto 
de E/S. 

En la IBM PC, el teclado contiene un microprocesador incorporado que se comunica a través de 
un puerto en serie especializado con un chip controlador en la tarjeta matriz. Se genera una interrupción 
cada vez que se pulsa una tecla y también cuando se suelta. Además, todo lo que el hardware del teclado 
proporciona es el número de tecla, no el código ASCII. Cuando se pulsa la 
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tecla A, se coloca el código de tecla (30) en un registro de E/S. Toca al controlador en software determinar 
si se trata de mayúscula, minúscula, CTRL-A, ALT-A, CTRL-ALT-A o alguna otra combinación. Puesto 
que el controlador sabe cuáles teclas se han pulsado pero todavía no se han soltado (p. ej., la tecla de 
mayúsculas), cuenta con suficiente información para realizar el trabajo. Aunque la interfaz del teclado 
deja toda la carga al software, es extremadamente flexible. Por ejemplo, los programas de usuario pueden 
estar interesados en si un dígito que se acaba de pulsar provino de la fila superior del teclado principal o 
del subteclado numérico que está a la derecha. En principio, el controlador puede proporcionar esta 
información. 


Terminales RS-232 

Las terminales RS-232 son dispositivos provistos de un teclado y una pantalla que se comunican 
por medio de una interfaz en serie, bit por bit (véase la Fig. 3-30). Estas terminales usan un conector de 9 
pins o de 25 pins, de las cuales una pin se usa para transmitir datos, una para recibir datos y una para 
tierra. Las demás pins son para diversas funciones de control, que en su mayor parte no se utilizan. Para 
enviar un carácter a una ter mi nal RS-232, la computadora debe transmitir un bit a la vez, anteponiendo un 
bit de inicio y anexando al final uno o dos bits de paro para delimitar el carácter. También puede insertarse 
un bit de paridad antes de los bits de paro, si se desea realizar una detección de errores rudimentaria, 
aunque esto generalmente sólo se exige en las comunicaciones con sistemas de macrocomputadoras. Las 
tasas de transmisión comunes son 9600,19 200 y 38 400 bps. Las ter mi nales RS-232 suelen utilizarse para 
la comunicación con una computadora remota a través de un módem y una línea telefónica. 
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Figura 3-30. Una ter mi nal RS-232 se comunica con una computadora a través de una línea de 
comunicación, bit por bit. La computadora y la terminal son totalmente independientes. 

Dado que tanto las computadoras como las terminales trabajan internamente con caracteres 
completos pero deben comunicarse por una línea serial con un bit a la vez, se han creado chips que 
realizan las conversiones de carácter a serie y de serie a carácter. Estos chips se denom in an UART 
(receptor transmisor universal asincrono) y se conectan a la computadora insertando tarjetas de interfaz 
RS-232 en el bus como se ilustra en la Fig. 3-30. Las terminales RS-232 se usan cada vez menos, pues 
están siendo sustituidas por PC y terminales X, pero todavía se encuentran en los sistemas de 
macrocomputadoras más antiguos, sobre todo en aplicaciones bancarias, de reservaciones de líneas aéreas 
y similares. 
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Para exhibir un carácter, el controlador en software de la terminal escribe el carácter en la taijeta 
de interfaz, donde se coloca en un buffer. De ahí, el UART lo desplaza hacia la línea serial bit por bit. 
Incluso a 38 400 bps, toma más de 250 microsegundos enviar un carácter. A causa de esta tasa de 
transmisión tan lenta, el controlador generalmente envía un carácter a la taijeta RS-232 y se bloquea, 
esperando la interrupción que la interfaz genera cuando ter mi na de trans mi tir el carácter y el ÜART está 
en condiciones de aceptar otro. El UART puede enviar y recibir caracteres simultáneamente, como indica 
su nombre. También se genera una interrupción cuando se recibe un carácter, y por lo regular es posible 
colocar en buffers un número pequeño de caracteres de entrada. El controlador de la terminal debe 
examinar un registro cuando se recibe una interrupción para determinar la causa de la interrupción. 
Algunas tarjetas de interfaz tienen una CPU y memoria capaces de manejar múltiples líneas, y asumen una 
buena parte de la carga de E/S de la CPU principal. 

Las terminales RS-232 se pueden subdividir en categorías, como ya se mencionó. Las más 
sencillas eran las ter mi nales de impresión. Los caracteres tecleados se transmitían a la computadora. Los 
caracteres enviados por la computadora se imprimían en el papel. Estas terminales son obsoletas y ya casi 
no se observan. 

Las terminales tontas de CRT funcionan de la misma manera, sólo que usan una pantalla en lugar 
de papel. Éstas también se conocen como "tty de vidrio", porque funcionalmente son iguales a las tty 
impresoras. (El término "tty" es una abreviatura de Teletype®, una compañía, ya desaparecida, que fue 
pionera en el negocio de las terminales para computadora; "tty", o "teletipo", suele usarse para referirse a 
cualquier terminal.) Las tty de vidrio también son obsoletas ya. 

Las ter mi nales inteligentes de CRT en realidad son pequeñas computadoras especializadas; tienen 
una CPU y memoria y contienen software, por lo regular en ROM. Desde el punto de vista del sistema 
operativo, la diferencia principal entre una tty de vidrio y una terminal inteligente es que la segunda 
entiende ciertas secuencias de escape. Por ejemplo, si enviamos el carácter ASCII ESC (033) seguido por 
varios otros caracteres, podemos mover el cursor a cualquier posición de la pantalla, insertar texto en 
medio de la pantalla, y otras cosas más. 


Terminales X 

La última palabra en terminales inteligentes es una ter mi nal que contiene una CPU tan potente 
como la de la computadora principal, junto con megabytes de memoria, un teclado y un ratón. Una 
ter mi n a l común de este tipo es la ter mi nal X, que ejecuta el sistema Ventana X del M.I.T. Por lo regular, 
las ter mi nales X hablan con la computadora principal a través de una Ethernet. 

Una ter mi nal X es una computadora que ejecuta el software X. Algunos productos están dedicados 
a ejecutar sólo X; otros son computadoras de propósito general que simplemente ejecutan X como un 
programa entre muchos más. En cualquier caso, una terminal X tiene una pantalla grande de mapa de bits, 
por lo regular con definición de 960 o° 1200 o más fina aún, en blanco y negro, escala de grises o color, 
un teclado completo y un ratón, normalmente con tres botones. 

El programa dentro de la ter mi nal X que obtiene entradas del teclado o del ratón y acepta 
comandos de una computadora remota se denomina servidor X. Este servidor se comunica a 
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través de la red con clientes X que se ejecutan en algún anfitrión remoto. Puede parecer extraño tener el 
servidor X dentro de la terminal y los clientes en el anfitrión remoto, pero el trabajo de servidor X consiste 
en exhibir bits, así que resulta lógico que esté cerca del usuario. La disposición de cliente y servidor se 
muestra en la Fig. 3-31. 


lernlMl X 



Figura 3-31. Clientes y servidores en el sistema X Ventana del M.I.T. 


La pantalla de la ter mi nal X contiene ventanas, cada una en forma de retícula rectangular de 
pixeles. Cada ventana por lo regular tiene una barra de título arriba, una barra de desplazamiento a la 
izquierda y un cuadro para redimensionar en la esquina superior derecha. Uno de los clientes X es un 
programa llamado administrador de ventanas, cuyo trabajo es controlar la creación, eli mi nación y 
desplazamiento de las ventanas en la pantalla. Para administrar las ventanas, este cliente envía comandos 
al servidor X indicándole qué debe hacer. Estos comandos incluyen dibujar punto, dibujar línea, dibujar 
rectángulo, dibujar polígono, llenar rectángulo, llenar polígono, etcétera. 

El trabajo del servidor X consiste en coordinar las entradas del ratón, del teclado y de los clientes 
X y actualizar la pantalla de manera acorde. El servidor debe saber cuál ventana está seleccionada 
actualmente (donde está el puntero del ratón) para determinar a cuál cliente debí enviar las nuevas 
entradas del teclado. 


3.9.2 Software de terminales 

El teclado y la pantalla son dispositivos casi independientes, así que aquí los estudiaremos por 
separado. (La independencia no es total, ya que los caracteres tecleados deben exhibirse en la pantalla.) En 
MINIX los controladores del teclado y de la pantalla forman parte de la misma tarea; | en otros sistemas 
pueden estar divididos en controladores distintos. 
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Software de entrada 

El trabajo básico del controlador de teclado consiste en obtener entradas del teclado y pasarlas a 
los programas de usuario cuando éstos lean de la terminal. Se pueden adoptar dos posibles filosofías para 
el controlador. En la primera, el controlador se limita a aceptar entradas y pasarlas más arriba sin 
modificarlas. Un programa que lee de la terminal obtiene una secuencia en bruto de códigos ASCII. 
(Proporcionar a los programas de usuario los números de tecla sería demasiado primitivo, además de ser 
muy dependiente de la máquina.) 

Esta filosofía es idónea para las necesidades de los editores de pantalla avanzados como emacs, 
que permiten al usuario ligar una acción arbitraria a cualquier carácter o secuencia de caracteres. Por otro 
lado, esta filosofía implica que si el usuario teclea dste en lugar de date y luego corrige el error pulsando 
tres veces la tecla de retroceso y escribiendo ate, seguido de un retomo de carro, el programa de usuario 
recibirá los 11 códigos ASCII tecleados. 

La mayor parte de los programas no desean tanto detalle; simplemente quieren la entrada 
corregida, no la secuencia exacta que la produjo. Esta observación nos lleva a la segunda filosofía: el 
controlador se encarga de toda la edición dentro de una línea, y entrega líneas corregidas a los programas 
de usuario. La primera filosofía está orientada a caracteres; la segunda está orientada a líneas. 
Originalmente, se llamaba a estas filosofías modo crudo y modo cocido, respectivamente. El estándar 
POSIX emplea el término menos pintoresco de modo canónico para describir el modo orientado a líneas. 
En la mayor parte de los sistemas el modo canónico se refiere a una configuración bien definida. El modo 
no canónico equivale al modo crudo, aunque es posible alterar muchos detalles del comportamiento de la 
terminal. Los sistemas compatibles con POSIX ofrecen varias funciones de biblioteca que permiten 
seleccionar cualquiera de los dos modos y modificar muchos aspectos de la configuración de la terminal. 
En MINIX, la llamada al sistema IOCTL apoya estas funciones. 

La primera tarea del controlador del teclado consiste en obtener caracteres. Si cada digitación 
causa una interrupción, el controlador puede adquirir el carácter durante la interrupción. Si el software de 
bajo nivel convierte las interrupciones en mensajes, es posible colocar el carácter recién adquirido en el 
mensaje. Como alternativa, el carácter puede colocarse en un buffer pequeño en la memoria y usarse el 
mensaje para indicarle al controlador que llegó algo. La segunda estrategia es más segura si sólo es 
posible enviar mensajes a procesos que están esperando y existe la posibilidad de que el controlador del 
teclado todavía esté ocupado con el carácter anterior. 

Una vez que el controlador ha recibido el carácter, debe comenzar a procesarlo. Si el teclado 
entrega números de tecla en lugar de los códigos de caracteres empleados por el software de aplicación, el 
controlador deberá realizar la conversión entre los códigos empleando una tabla. No todas las 
"compatibles con IBM" usan la numeración de teclas estándar, así que si el controlador desea apoyar tales 
máquinas deberá establecer una correspondencia entre los diferentes teclados y diferentes tablas. Una 
estrategia sencilla consiste en compilar una tabla que establece una correspondencia entre los códigos 
proporcionados por el teclado y los códigos ASCII (American Standard Code for Information Interchange) 
en el controlador del teclado, pero esto no resulta satisfactorio para usuarios de lenguajes distintos del 
inglés. Los teclados tienen diferente organización en los distintos países, y el conjunto de caracteres 
ASCII no resulta adecuado ni siquiera 
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para la mayoría de los usuarios del Hemisferio Occidental, donde los hablantes de español, portugués y 
francés requieren caracteres acentuados y signos de puntuación que no se utilizan en el inglés. A fin de 
responder a la necesidad de una organización de teclado flexible adaptable a diferentes idiomas, muchos 
sistemas operativos ofrecen mapas de teclas o páginas de código cargables, que permiten escoger la 
correspondencia entre los códigos del teclado y los códigos proporcionados a la aplicación, ya sea cuando 
se arranca el sistema o posteriormente. 

Si la ter mi nal está en modo canónico (cocido), los caracteres deben almacenarse hasta que se 
acumule una línea completa, porque el usuario podría decidir subsecuentemente borrar una parte. Incluso 
si la terminal está en modo crudo, es posible que el programa todavía no haya solicitado entradas, por lo 
que los caracteres deben colocarse en un buffer para permitir el tecleo adelantado. (A los diseñadores de 
sistemas que no permiten a los usuarios teclear por adelantado muchos caracteres se les debería untar de 
brea y cubrir de plumas o, peor aún, se les debería obligar a usar su propio sistema.) 

Hay dos enfoques comunes para el almacenamiento en buffer de los caracteres. En el primero, el 
controlador cuenta con una reserva central de buffers, cada uno de los cuales puede contener tal vez 10 
caracteres. Cada terminal tiene asociada una estructura de datos que contiene, entre otras cosas, un 
apuntador a la cadena de buffers para las entradas obtenidas de esa terminal. Al teclearse más caracteres, 
se adquieren más buffers y se anexan a la cadena. Cuando los caracteres se pasan a un programa de 
usuario, los buffers se retiran y se devuelven a la reserva central. 

El otro enfoque consiste en realizar el almacenamiento intermedio en la estructura de datos de la 
terminal misma, sin una reserva central de buffers. Puesto que es común que los usuarios tecleen un 
comando que tardará cierto tiempo (digamos, una compilación) y luego tecleen unas cuantas líneas por 
anticipado, el controlador deberá, por seguridad, asignar algo así como 200 caracteres por terminal. En un 
sistema de tiempo compartido a gran escala con 100 terminales, la asignación de 20K permanentemente 
para el tecleo adelantado es obviamente una exageración, y en este caso seguramente bastará con una 
reserva central de buffers con espacio para unos 5K. Por otro lado, tener un buffer dedicado por terminal 
hace que el controlador sea más sencillo (pues no tendrá que manejar una lista enlazada) y es preferible en 
las computadoras personales con sólo una o dos terminales. En la Fig. 3-32 se muestra la diferencia entre 
estos dos métodos. 

Si bien el teclado y la pantalla son dispositivos lógicamente independientes, muchos usuarios 
están acostumbrados a ver en la pantalla los caracteres que acaban de teclear. Algunas terminales 
(antiguas) complacen al usuario en este sentido exhibiendo automáticamente (en hardware) todo lo que se 
teclea. Esto es un problema no sólo cuando se están introduciendo contraseñas, sino porque limita 
considerablemente la flexibilidad de los editores avanzados y de otros programas. Por fortuna, la mayor 
parte de las terminales modernas no exhiben nada cuando se está tecleando; es obligación del software 
exhibir las entradas. Este proceso se denomina eco. 

El eco se complica por el hecho de que un programa podría estar escribiendo en la pantalla 
mientras el usuario está tecleando. Como mínimo, el controlador del teclado tendrá que buscar dónde 
poner las entradas nuevas para que no sean sobreescritas por las salidas del programa. 

El eco también se complica cuando se teclean más de 80 caracteres en una terminal que tiene 
l ín eas de 80 caracteres. Dependiendo de la aplicación, puede ser apropiado o no continuar en la 
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Figura 3-32. (a) Reserva central de buffers. (b) Buffer dedicado para cada terminal. 


siguiente línea. Algunos controladores simplemente truncan las líneas a 80 caracteres desechando todos 
los caracteres más allá de la columna 80. 

Otro problema es el manejo de las tabulaciones. La mayor parte de las terminales tienen una tecla 
de tabulación, pero pocas pueden manejar las tabulaciones en las salidas. Corresponde al controlador 
calcular la posición actual del cursor, teniendo en cuenta tanto las salidas de los programas como la salida 
del eco, y calcular el número correcto de espacios que deben exhibirse. 

Ahora llegamos al problema de la equivalencia de dispositivos. Lógicamente, al final de una línea 
de texto habría que tener un retomo de carro, para regresar el cursor a la columna 1, y un salto de línea, 
para avanzar a la siguiente línea. A los usuarios seguramente no les gustaría tener que teclear ambas cosas 
al final de cada línea (aunque algunas terminales tienen una tecla que genera estos dos caracteres, con una 
probabilidad del 50% de hacerlo en el orden en que el software lo desea). Toca al controlador convertir 
todo lo que llega al formato interno estándar empleado por el sistema operativo. 

Si la forma estándar consiste en almacenar simplemente un salto de línea (la convención en 
MINIX), los retomos de carro deberán convertirse en saltos de línea. Si el formato intemo consiste en 
almacenar las dos cosas, el controlador deberá generar un salto de línea cuando reciba un retomo de carro 
y un retomo de carro cuando reciba un salto de línea. Sea cual sea la convención intema, es posible que la 
terminal requiera que se haga eco tanto de un retomo de carro como de un salto de línea para que la 
pantalla se actualice correctamente. Dada la posibilidad de que una computadora grande tenga una amplia 
variedad de ter mi nales diferentes conectadas a ella, es obligación del controlador del teclado hacer que 
todas las combinaciones de retomo de carro y salto de línea se conviertan al estándar interno del sistema y 
que se haga eco de todo lo necesario. 

Un problema relacionado es el de los tiempos de los retomos de carro y saltos de línea. En algunas 
terminales puede requerirse más tiempo para e xh ibir un retomo de carro o un salto de 
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línea que una letra o un número. Si el microprocesador dentro de la terminal tiene que copiar un bloque 
grande de texto para efectuar el desplazamiento de la pantalla, es posible que los saltos de linea sean 
lentos. Si es necesario regresar una cabeza de impresión mecánica al margen izquierdo del papel, los 
retomos de carro pueden ser lentos. En ambos casos es responsabilidad del controlador insertar caracteres 
de llenado (caracteres nulos ficticios) en el flujo de salida o simplemente dejar de producir salidas durante 
el tiempo suficiente para que la terminal se ponga al día. La duración del retraso a menudo está 
relacionada con la rapidez de la terminal; por ejemplo, a 4800 bps o menos tal vez no se requieran 
retrasos, pero a 9600 bps o más podría requerirse un carácter de relleno. Las ter mi nales con tabulaciones 
en hardware, sobre todo las de copia impresa, podrían requerir también un retraso después de una 
tabulación. 


Cuando se opera en modo canónico, varios caracteres de entrada tienen un significado especial. 
En la Fig. 3-33 se muestran todos los caracteres especiales requeridos por POSIX y los adicionales que 
MINIX reconoce. Los caracteres predeterminados son caracteres de control que no deberán causar 
conflictos con las entradas de texto ni los códigos utilizados por los programas, pero todos con excepción 
de los dos últimos pueden modificarse con el comando stty, si se desea. Las versiones antiguas de UNIX 
empleaban diferentes caracteres por omisión para muchos de éstos. 


Carácter 

Nombre POSEÍ 

Comentario 

CTRL-D 

EOF 

Fin de archivo 


EOL 

Fin de línea (no definido) 

CTRL-H 

ERASE 

Retroceder un carácter 

DEL 

INTR 

Interrumpir proceso (SIGINT) 

CTRL-U 

KILL 

Borrar toda la línea tecleada 

CTRL-\ 

QUIT 

Forzar vaciado de núcleo (SIQQUIT) 

CTRL-Z 

SUSP 

Suspender (MINIX lo ignora) 

CTRL-Q 

START 

Iniciar salidas 

CTRL-S 

STOP 

Detener salidas 

CTRL-R 

REPRINT 

Reexhibir entradas (extensión de MINIX) 

CTRL-V 

LNEXT 

Sigue literal (extensión de MINIX) 

CTRL-0 

DISCARD 

Desechar salidas (extensión de MINIX) 

CTRL-M 

CR 

Retomo de carro (no modificable) 

CTRL-J 

NL 

Salto de línea (no modificable) 


Figura 3-33. Caracteres que se manejan de forma especial en modo canónico. 


El carácter ERASE permite al usuario borrar el carácter que acaba de teclearse. En MINIX se usa 
para ello el retroceso (CTRL-H). Este carácter no se agrega a la cola de caracteres; más bien, quita de la 
cola el carácter anterior. El eco de este carácter debe consistir en una secuencia de tres caracteres, 
retroceso, espacio y retroceso, a fin de borrar el carácter anterior de la pantalla. Si el 
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carácter anterior era una tabulación, para borrarlo será necesario saber dónde estaba el cursor antes de la 
tabulación. En la mayor parte de los sistemas, el retroceso sólo borra caracteres de la línea actual; no borra 
el retomo de carro ni continúa con la línea anterior. 

Cuando el usuario observa un error al principio de la línea que está tecleando, muchas veces es 
más cómodo borrar toda la línea y comenzar otra vez. El carácter KILL (CTRL-U en MINIX) borra toda 
la línea. MINIX hace que la línea borrada desaparezca de la pantala, pero algunos sistemas hacen eco de 
ella junto con un retomo de carro y un salto de línea porque a algunos usuarios les gusta ver la línea vieja. 
Por tanto, la forma como se hace eco de KILL es cuestión de gustos. Al igual que con ERASE, 
normalmente no es posible regresar más allá de la línea en curso. Cuando se elimina un bloque de 
caracteres, podría o no valer la pena que el controlador devuelva buffers a la reserva, si se usa. 

A veces los caracteres ERASE o KILL deben introducirse como datos ordinarios. El carácter 
LNEXT sirve como carácter de escape. En MINIX CTRL-V es lo predeterminado. Por ejemplo, los 
primeros sistemas UNIX a menudo usaban el signo @ para KILL, pero el sistema de correo de Internet 
utiliza direcciones de la forma linda@cs.washington.edu. Alguien que se sienta más cómodo con las 
convenciones antiguas podría redefinir KILL como @, pero después podría necesitar introducir un signo 
@ literalmente para especificar una dirección de correo electrónico. Esto puede hacerse tecleando CTRL- 
V @. El CTRL-V mismo se puede introducir literalmente tecleando CTRL-V CTRL-V. Después de ver el 
CTRL-V, el controlador enciende una bandera que indica que el siguiente carácter está exento de 
procesamiento especial. El carácter LNEXT mismo no se coloca en la cola de caracteres. 

En caso de que el usuario desee detener una imagen en la pantalla para que no desaparezca por el 
desplazamiento, se proporcionan códigos de control para congelar la pantalla y reactivarla después. En 
MINIX estos códigos son STOP (CTRL-S) y START (CTRL-Q), respectivamente.Éstos no se almacenan, 
sino que se usan para encender y apagar (izar y bajar) una bandera en la estructura de datos de la terminal. 
Cada vez que se intenta producir salidas, se examina la bandera. Si la bandera está encendida, no habrá 
salida. Casi siempre el eco también se suprime junto con las salidas de los programas. 

En muchos casos es necesario ter mi nar un programa fuera de control que se está depuando. Los 
caracteres INTR (DEL) y QUIT (CTRL-Y) pueden servir para este fin. En MINIX, DEL (SUPR) envía la 
señal SIGINT a todos los procesos iniciados en la terminal. La implementación de DEL puede ser 
complicada. La parte difícil es hacer que la información del controlador llegue a la parte del sistema que 
maneja las señales, la cual, después de todo, no ha solicitado esta información. CTRLA es similar a DEL, 
excepto que envía la señal SIGQUIT, que obliga a un vaciado de núcleo si no es atrapada o ignorada. 
Cuando se pulsa cualquiera de estas teclas, el controlador deberá hacer eco de un retomo de carro y un 
salto de línea y desechar todas las entradas acumuladas a fin de iniciar desde cero. El valor por omisión de 
INTR muchas veces es CTRL-C en lugar de DEL, ya que muchos programas usan DEL para edición, 
además de la tecla de retroceso. 

Otro carácter especial es EOF (CTRL-D), que en MINIX hace que cualquier petición de lectura de 
la terminal pendiente se satisfaga con lo que esté disponible en el buffer, incluso si éste está vacío. Si se 
teclea CTRL-D al principio de una línea, el programa obtiene una lectura de O 
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bytes, lo que convencionalmente se interpreta como un fin de archivo y hace que la mayor parte de los 
programas actúen tal como lo harían al detectar un fin de archivo en un archivo de entrada. 

Algunos controladores de terminal permiten realizar actividades de edición dentro de la línea 
mucho más avanzadas que las que hemos bosquejado aquí. Esos controladores cuentan con caracteres de 
control especiales para borrar una palabra, saltar caracteres o palabras hacia atrás o hacia adelante, ir al 
principio o al final de la línea que se está tecleando, etc. La adición de todas estas funciones al controlador 
de la terminal lo hace mucho más grande y, además, es un desperdicio cuando se usan editores de pantalla 
avanzados que de todas maneras trabajan en modo crudo. 

Con objeto de que los programas puedan controlar los parámetros de las terminales, POSIX exige 
que estén disponibles varias funciones en la biblioteca estándar, siendo las más importantes tcgetattr y 
tcsetattr. Tcgetattr obtiene una copia de la estructura que se muestra en la Fig. 3-34, llamada termios, que 
contiene toda la información necesaria para cambiar caracteres especiales, establecer modos y modificar 
otras características de una terminal. Un programa puede examinar los valores actuales y modificarlos si 
lo desea. Luego, tcsetattr escribe la estructura otra vez en la tarea de la terminal. 

struct termios { 


tcflagt cJflag; 

/* modos de entrada */ 

tcflag t c oflag; 

/* modos de salida */ 

tcflagt ccflag; 

/* modos de control */ 

tcflag t cJflag; 

/* modos locales */ 

speedt cJspeed; 

/* velocidad de entrada */ 

speedt cospeed; 

/* velocidad de salida */ 

cc_t c_cc[NCCS]; 

/* caracteres de control */ 


Figura 3-34. La estructura termios. En MINIX, tcflagt es un short, speedt es un int y cc_t 
es un char. 

POSIX no especifica si sus requisitos deben implementarse mediante funciones de biblioteca o 
llamadas al sistema. MINIX ofrece una llamada al sistema, IOCTL, invocada por 

ioctl(descriptor_archivo, solicitud, argp); 

que sirve para examinar y modificar las configuraciones de muchos dispositivos de E/S. Esta llamada se 
usa para implementar las funciones tcgetattr y tcsetattr. La variable solicitud especifica si se debe leer o 
escribir la estructura termios y, en caso de que se vaya a escribir, si la petición debe atenderse de 
inmediato o diferirse hasta que se hayan completado todas las salidas que actualmente están en cola. La 
variable argp es un apuntador a una estructura termios en el programa invocador. Esta forma específica de 
comunicación entre los programas y el controlador se escogió por su compatibilidad con UNIX, más que 
por su belleza inherente. 

Es apropiado incluir unas cuantas notas acerca de la estructura ter mi os. Las cuatro palabras de 
banderas ofrecen mucha flexibilidad. Los bits individuales de c iflag controlan diversas formas de 
manejar las entradas. Por ejemplo, el bit ICRNL hace que los caracteres CR de las entradas se conviertan 
en NL. Esta bandera se enciende por omisión en MINIX. La palabra coflag 
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contiene bits que afectan el procesamiento de las salidas. Por ejemplo, el bit OPOST habilita el 
procesamiento de las salidas. Ese bit y el bit ONLCR, que hace que los caracteres NL de la salida se 
conviertan en una secuencia CR NL, también están encendidos por omisión en MINIX. Ccflag es la 
palabra de banderas de control. Los valores por omisión para MINIX permiten que una línea reciba 
caracteres de 8 bits y hacen que un módem cuelgue si un usuario termina una sesión en la línea. Clflag es 
el campo de banderas de modo local. Un bit, ECHO, habilita el eco (y puede apagarse durante un inicio de 
sesión para que la introducción de la contraseña sea más segura). El bit más importante aquí es ICANON, 
que habilita el modo canónico. Con ICANON apagado, hay varias posibilidades. Si todos los demás bits 
se dejan con sus valores predeterminados, se ingresa en un modo idéntico al modo cbreak tradicional. En 
este modo, los caracteres se pasan al programa sin esperar hasta completar una línea, pero los caracteres 
INTR, QUIT, STARTy STOP conservan sus efectos. Todos éstos pueden inhabilitarse poniendo en cero 
los bits en las banderas, produciendo así el equivalente del modo crudo tradicional. 

Los diversos caracteres especiales que pueden modificarse, incluidos los que son extensiones de 
MINIX, se guardan en el arreglo c_cc. Este arreglo también contiene dos parámetros que se usan en el 
modo no canónico. La cantidad MIN, almacenada en c_cc[VMIN}, especifica el número mínimo de 
caracteres que deben recibirse para satisfacer una llamada READ. La cantidad TIME de c_cc[VTIME} 
establece un límite de tiempo para tales llamadas. MIN y TIME interactúan como se muestra en la Fig. 3- 
35. Se ilustra una llamada que solicita N bytes. Con TIME = O y MIN = 1, el comportamiento es similar 
al modo crudo tradicional. 



TIME=0 

TIME > 0 

MIN=0 

Regresa inmediatamente 
con lo que hay 

disponible, 0 a N bytes 

El temporizador inicia de inmediato. Regresa con el primer 
byte introducido o con 0 bytes después del tiempo de 
espera 

MIN>0 

Regresa con por lo 
menos MIN y hasta N 
bytes. Posible bloqueo 
indefinido 

El temporizador entre bytes se inicia después delprimer 
byte. Devuelve N bytes si se han recibido cuando vence el 
tiempo o por lo menos un byte al vencer el tiempo. Posible 
bloqueo indefinido 


Figura 3-35. MIN y TIME determinan cuándo una llamada de lectura regresa en modo 
no canónico. N es el número de bytes solicitados. 


Software de salida 

La salida es más sencilla que la entrada, pero los controladores para las terminales RS-232 son 
radicalmente diferentes de los controladores para las ter mi nales con mapa en la memoria. El método que 
suele usarse en las terminales RS-232 es tener buffers de salida asociados con cada terminal. Los buffers 
pueden provenir de la misma reserva que los buffers de entrada, o ser dedicados, como en el caso de las 
entradas. Cuando los programas escriben en la terminal, la salida se copia primero en los buffers. De 
forma similar, las salidas del eco se copian también en los buffers. Una vez que todas las salidas se han 
copiado en los buffers (o que éstos están llenos), 
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se exhibe el primer carácter, y el controlador se duerme. Cuando llega la interrupción, se exhibe el 
siguiente carácter, y así sucesivamente. 

En las terminales con mapa en la memoria se puede usar un esquema más sencillo. Los caracteres 
que se van a exhibir se extraen uno por uno del espacio de usuario y se colocan directamente en la RAM 
de video. En las ter mi nales RS-232, cada carácter por exhibir se envía simplemente por la línea hacia la 
terminal. Cuando hay mapa en la memoria, algunos caracteres requieren un tratamiento especial, como el 
retroceso, el retomo de carro, el salto de línea y la alarma audible (CTRL-G). Un controlador para una 
terminal con mapa en la memoria debe seguir la pista en software a la posición actual en la RAM de 
video, a fin de poder colocar caracteres imprimibles ahí y avanzar la posición actual. El retroceso, el 
retomo de carro y el salto de línea requieren que dicha posición se actualice de forma apropiada. 

En particular, cuando se produce un salto de línea en la línea inferior de la pantalla, es preciso 
hacer avanzar la pantalla. Para ver cómo funciona el desplazamiento, examine la Fig. 3-29. Si el 
controlador de video siempre comenzara a leer la RAM en OxBOOOO, la única forma de hacer avanzar la 
pantalla sería copiando 24 x 80 caracteres (cada uno de los cuales requiere dos bytes) de OxBOOAO a 
OxBOOOO, cosa que tardaría un tiempo apreciable. 

Por fortuna, el hardware generalmente ofrece algo de ayuda aquí. La mayor parte de los 
controladores de video contienen un registro que determina de qué punto de la RAM de video deben 
comenzarse a tomar los caracteres para la línea superior de la pantalla. Si hacemos que este registro apunte 
a OxBOOAO en lugar de a OxBOOOO, la línea que antes era la número dos pasará a ser la primera, y 
toda la pantalla se desplazará hacia arriba una línea. La única otra cosa que el controlador en software 
debe hacer es copiar lo necesario en la nueva línea inferior. Cuando el controlador de video llega a la parte 
superior de la RAM, simplemente da la vuelta y continúa obteniendo bytes a partir de la dirección más 
baja. 

Otro problema que el controlador en software debe resolver en una terminal con mapa en la 
memoria es la colocación del cursor. Una vez más, el hardware ayuda un poco en forma de un registro que 
indica dónde debe ir el cursor. Por último, está el problema de la alarma, la cual se produce enviando una 
onda senoidal o cuadrada al altavoz, que es una parte de la computadora totalmente independiente de la 
RAM de video. 

Vale la pena señalar que muchos de los problemas que enfrenta el controlador de una terminal con 
pantalla mapeada en la memoria (desplazamiento, alarma, etc.), también los enfrenta el microprocesador 
de una terminal RS-232. Desde el punto de vista del microprocesador, él es el procesador principal de un 
sistema con pantalla mapeada en la memoria. 

Los editores de pantalla y muchos otros programas avanzados necesitan poder actualizar la 
pantalla de formas más complejas que simplemente desplazar texto en la parte inferior de la pantalla. A fin 
de darles servicio, muchos controladores de ter mi nal reconocen diversas secuencias de escape. Aunque 
algunas terminales reconocen conjuntos de secuencias de escape especiales, conviene tener un estándar 
que facilite la adaptación del software de un sistema a otro. El American National Standards Institute 
(ANSÍ) ha definido un conjunto de secuencias de escape estándar, y MINIX reconoce un subconjunto de 
las secuencias ANSÍ que se muestra en la Fig. 3-36 y que es suficiente para muchas operaciones comunes. 
Cuando el controlador detecta el carácter que inicia las secuencias de escape, enciende una bandera y 
espera hasta que llega el resto de la 
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secuencia de escape. Una vez que ha llegado todo, el controlador debe realizar la acción correspondiente 
en software. La inserción y eli mi nación de texto requieren la transferencia de bloques de caracteres dentro 
de la RAM de video. El hardware no ayuda más que con el desplazamiento de la pantalla y la exhibición 
del cursor. 


Secuencia de escape 

Significado 

ESC [ n A 

Subir n líneas 

ESC [ n B 

Bajar n líneas 

ESC [ n C 

Moverse n espacios a la derecha 

ESC [ n D 

Moverse n espacios a la izquierda 

ESC [ m: n H 

Llevar el cursor a (m, n) 

ESC [ s J 

Borrar la pantalla desde el cursor (0 al final, 1 desde el principio, 2 
todo) 

ESC [ s K 

Borrar la línea desde el cursor (0 al final, 1 desde el principio, 2 
todo) 

ESC [ n L 

Insertar n líneas en el cursor 

ESC [ n M 

Borrar n líneas en el cursor 

ESC [ n P 

Borrar n caracteres en el cursor 

ESC [ n @ 

Insertar n caracteres en el cursor 

ESC [nm 

Habilitar presentación n (0=normal, 4=negrita, 5=parpadeante, 
7=¡nverso) 

ESCM 

Desplazar la pantalla hacia atrás si el cursor está en la línea superior 


Figura 3-36. Las secuencias de escape ANSÍ aceptadas por el controlador de terminal para salida. ESC 
denota el carácter de escape ASCII (OxIB), y n, m y s son parámetros numéricos opcionales. 

3.9.3 Generalidades del controlador de terminales en MINIX 

El controlador de ter mi nales está contenido en cuatro archivos en C (seis si está habilitado el 
apoyo de RS-232 y seudoterminal) y juntos constituyen por mucho el controlador más grande de MINIX. 
El tamaño del controlador de terminales se explica en parte por la observación de que el controlador 
maneja tanto el teclado como la pantalla, cada uno de los cuales es un dispositivo complejo por derecho 
propio, así como otros dos tipos opcionales de terminales. No obstante, la mayoría de las personas se 
sorprende al enterarse de que la E/S de terminal requiere 30 veces más código que el planificador. (Esta 
sensación se refuerza si se examinan los numerosos libros sobre sistemas operativos que dedican un 
espacio 30 veces mayor a la planificación que a toda la E/S combinada.) 

El controlador de ter mi nal acepta siete tipos de mensajes: 

1. Leer de la ter mi nal (del sistema de archivos a nombre de un proceso de usuario). 

2. Escribir en la ter mi nal (del sistema de archivos a nombre de un proceso de usuario). 

3. Establecer parámetros de la term in al para IOCTL (del sistema de archivos a nombre de un 
proceso de usuario). 
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4. E/S ocurrida durante el último tic del reloj (del manejador de interrupciones de reloj). 

5. Cancelar la petición anterior (del sistema de archivos cuando ocurre una señal). 

6. Abrir un dispositivo. 

7. Cerrar un dispositivo. 


Los mensajes para leer y escribir tienen el mismo formato que se mostró en la Fig. 3-15, excepto 
que no se necesita el campo POSITION. En el caso de un disco, el programa debe especificar cuál bloque 
desea leer. En el caso de una terminal, no hay opción: el programa siempre obtiene el siguiente carácter 
que se teclea. Las terminales no realizan búsquedas. 

Las fúnciones de POSIX tcgetattr y tcsetattr que sirven para examinar y modificar los atributos 
(propiedades) de las ter mi nales están apoyadas por la llamada al sistema IOCTL. Según la práctica de 
programación recomendada, hay que usar estas fúnciones y otras que están en include/termios.h y dejar 
que la biblioteca de C convierta las llamadas de biblioteca a llamadas al sistema IOCTL. Sin embargo, hay 
algunas operaciones de control que MINIX necesita y que no están contempladas en POSIX, como cargar 
un mapa de teclas alterno, y para éstas el programador debe usar IOCTL explícitamente. 

El mensaje enviado al controlador por una llamada al sistema IOCTL, contiene un código de 
petición de fúnción y un apuntador. En el caso de la función tcsetattr, se realiza una llamada IOCTL con 
un tipo de petición TCSETS, TCSETSW o TCSETSF, y un apuntador a una estructura termios como la 
que se muestra en la Fig. 3-34. Todas estas llamadas reemplazan el conjunto vigente de atributos por un 
conjunto nuevo; las diferencias radican en que una petición TCSETS tiene efecto inmediato, una petición 
TCSETSW sólo surte efecto hasta que se han transmitido todas las salidas, y una TCSETSF espera a que 
las salidas terminen y desecha todas las entradas que todavía no se han leído. Tcgetattr se traduce a una 
llamada IOCTL con un tipo de petición TCGETS y devuelve al invocador una estructura termios llena 
para que pueda examinar el estado actual de un dispositivo. Las llamadas IOCTL que no corresponden a 
funciones definidas por POSIX, como la petición KIOCSMAP empleada para cargar un nuevo mapa de 
teclas, pasan apuntadores a otros tipos de estructuras, en este caso a una keymapt que es una estructura 
de 1536 bytes (códigos de 16 bytes para 128 teclas X 6 modificadores). En la Fig. 3-43 se resume la forma 
en que las llamadas POSIX estándar se convierten en llamadas al sistema IOCTL. 

El controlador de ter mi nal usa una estructura de datos principal, tty table, que es un arreglo de 
estructuras tty, una por terminal. Una PC estándar sólo tiene un teclado y una pantalla, pero MINIX puede 
reconocer hasta ocho term in ales virtuales, dependiendo de la cantidad de memoria que tenga la tarjeta del 
adaptador de pantalla. Esto permite a la persona que usa la consola iniciar varias sesiones, conmutando la 
salida de la pantalla y la entrada del teclado de un "usuario" a otro. Con dos consolas virtuales, si 
oprimimos ALT-F2 seleccionaremos la segunda y con ALT-F1 regresaremos a la primera. También puede 
usarse ALT junto con la tecla de flecha. Además, las líneas en serie pueden apoyar a dos usuarios remotos 
conectados por un cable RS-232 o un módem, y las seudoterminales pueden apoyar a usuarios conectados 
a través de una red. El controlador se escribió con el fin de facilitar la adición de más terminales. La 
configuración estándar que se 
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ilustra en el código fuente del presente texto tiene dos consolas virtuales, con las líneas en serie y las 
seudoterminales inhabilitadas. 

Cada estructura tty de ttytable sigue la pista tanto a las entradas como a las salidas. Para la 
entrada, la estructura contiene una cola de todos los caracteres que se han tecleado pero que el programa 
todavía no ha leído, información relativa a peticiones de lectura de caracteres que todavía no se han 
recibido e información de tiempos de espera para poder solicitar entradas sin -que la tarea se bloquee 
permanentemente si no se teclea ningún carácter. Para la salida, la estructura contiene los parámetros de 
las peticiones de escritura que todavía no han terminado. Otros campos contienen diversas variables 
generales, como la estructura termios ya mencionada, que afectan muchas propiedades tanto de las 
entradas como de las salidas. También hay un campo en la estructura tty que apunta a información que se 
necesita para una clase específica de dispositivos pero que no tiene que estar en la entrada de tty table 
para todos y cada uno de los dispositivos. Por ejemplo, la parte del controlador de la consola dependiente 
del hardware necesita la posición actual en la pantalla y en la RAM de video, y el byte de atributo vigente 
para la pantalla, pero esta información no es necesaria para apoyar una línea RS-232. Las estructuras de 
datos privadas para cada tipo de dispositivo también contienen los buffers que reciben entradas de las 
rutinas de servicio de interrupciones. Los dispositivos lentos, como el teclado, no necesitan buffers tan 
grandes como los que necesitan los dispositivos rápidos. 


Entradas de terminales 


A fin de entender mejor el funcionamiento del controlador, examinemos primero la forma como 
los caracteres que se teclean en la ter mi nal se abren ca mi no a través del sistema hasta el programa que los 
necesita. 

Cuando un usuario inicia una sesión en la consola del sistema, se crea un shell para él con 
/dev/console como entrada estándar, salida estándar y error estándar. El shell inicia y trata de leer de la 
entrada estándar invocando el procedimiento de biblioteca read. Este procedimiento envía al sistema de 
archivos un mensaje que contiene el descriptor de archivo, la dirección del buffer y la cuenta. Este 
mensaje está rotulado como (1) en la Fig. 3-37. Después de enviar el mensaje, el shell sé bloquea, 
esperando la respuesta. (Los procesos de usuario sólo ejecutan la primitiva SEND REC, que combina un 
SEND con un RECEIVE del proceso al que se envió.) 

El sistema de archivos recibe el mensaje y localiza el nodo i que corresponde al descriptor de 
archivo especificado. Este nodo i es el del archivo especial por caracteres /dev/console y contiene los 
números de dispositivo principal y secundario de la terminal. El número de dispositivo principal para las 
terminales es 4; para la consola, el número de dispositivo secundario es 0. 

El sistema de archivos utiliza estos números como índices para buscar en su mapa de dispositivos, 
dmap, el número de la tarea de la terminal, y luego envía a dicha tarea un mensaje que «parece como (2) 
en la Fig. 3-37. Normalmente, el usuario todavía no habrá tecleado nada, así que el controlador de la 
term in al no podrá satisfacer la petición. El controlador devuelve de inmeteto una respuesta para 
desbloquear el sistema de archivos e informar que no hay caracteres disponibles; esta respuesta aparece 
como (3). El sistema de archivos toma nota del hecho de que un proceso está esperando entradas de la 
terminal, registrándolo en la estructura de la consola en 
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Figura 3-37. Petición de lectura de la terminal cuando no hay caracteres pendientes. FS es el 
sistema de archivos. TTY es la tarea de la terminal. El manejador de interrupciones de la 
ter mi nal pone en cola los caracteres conforme se introducen, pero es el manejador de inte¬ 
rrupciones del reloj el que despierta a TTY. 


tty table, y luego se pone a obtener la siguiente petición de trabajo. Desde luego, el shell del usuario 
permanece bloqueado hasta que llegan los caracteres solicitados. 

Cuando por fin se escribe un carácter en el teclado, causa dos interrupciones: una cuando la tecla 
se oprime y otra cuando se suelta. Esta regla también aplica a las teclas modificadoras como CTRL y 
SHIFT, que no transmiten datos por sí mismas pero que de todos modos causan dos interrupciones por 
tecla. La interrupción del teclado es IRQ 1, y hwintOl en el archivo de código de ensamblador mpx386.s 
activa kbdhwint (línea 13123), que a su vez invoca scan keyboard (línea 13432) para extraer el código 
de tecla del hardware del teclado. Si el código es el de un carácter ordinario, se coloca en la cola de 
entrada del teclado, ibuf, si la interrupción se generó al oprimirse una tecla, pero se ignora si la 
interrupción se generó al soltarse una tecla. Los código para las teclas modificadoras como CTRL y 
SHIFT se colocan en la cola cuando ocurren ambos tipos de interrupciones, pero pueden distinguirse 
después por un bit que se pone en 1 cuando se suelta una tecla. Observe que en este punto los códigos 
recibidos y almacenados en ibuf no son códigos ASCII; simplemente son los códigos de escrutinio 
producidos por el teclado IBM. A continuación, kbd hw int enciende una bandera, tty events (parte de la 
sección de tty table que corresponde al teclado), invoca force timeoul para forzar el vencimiento del 
tiempo de espera, y regresa 

A diferencia de algunas otras rutinas de servicio de interrupciones, kbd hw int no envía IBM 
ensaje para despertar la tarea de la terminal. La llamada a.forceJ.imeout se indica con las líneas 
interrumpidas marcadas con (4) en la figura. Estas no son mensajes; establecen la variable ttytimeout en 
el espacio de direcciones común a todas las rutinas de servicio de interrupciones. En la siguiente 
interrupción del reloj, clock handler ve que tty timeout indica que es el momento de invocar tty wakeup 
(línea 11452), la cual envía un mensaje (5) a la tarea de la terminal para 
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despertarla. Observe que si bien el código fuente para tty wakeup está en el archivo tty.c, se ejecuta en 
respuesta a la interrupción de reloj, y por esta razón decimos que la interrupción de reloj envía el mensaje 
a la tarea de la terminal. Si las entradas están llegando rápidamente, pueden ponerse en cola de esta forma 
varios códigos de carácter, y es por ello que se muestran múltiples llamadas aforcetimeout (4) en la 
figura. 

Al recibir el mensaje de despertar, la tarea de terminal examina la bandera tty events de cada 
dispositivo de terminal y, para cada dispositivo que tiene su bandera izada, invoca handleevents (línea 
12256). La bandera tty events puede indicar diversos tipos de actividades (aunque la entrada es el más 
probable), así que handlee vents siempre invoca las funciones específicas para el dispositivo tanto para 
las entradas como para las salidas. Cuando hay entradas del teclado, el resultado es una llamada a kbread 
(línea 13165), que sigue la pista a los códigos de teclado que indican la pulsación o liberación de las teclas 
CTRL, SHIFT y ALT y convierte los códigos del teclado en códigos ASCII. A su vez, kb read invoca in_ 
process (línea 12367), que procesa los códigos ASCII, teniendo en cuenta los caracteres especiales y las 
diferentes banderas que pueden estar izadas, incluida la que indica si está vigente o no el modo canónico. 
El efecto normal es agregar caracteres a la cola de entrada de la consola en tty table, aunque algunos 
códigos, como por ejemplo BACKSPACE (retroceso), tienen otros efectos. Normalmente, in_process 
inicia también el eco de los códigos ASCII a la pantalla. 

Una vez que han llegado suficientes caracteres, la tarea de la terminal invoca el procedimiento en 
lenguaje ensamblador physcopy para copiar los datos en la dirección solicitada por el shell. Esta 
operación tampoco es una transferencia de mensajes, y por esa razón se muestra con las líneas punteadas 
(6) en la Fig. 3-37. Se muestra más de una línea de éstas porque pueden realizarse más de una operación 
de este tipo antes de que se satisfaga plenamente la petición del usuario. Una vez completada la operación, 
el controlador de la terminal envía un mensaje al sistema de archivos para informarle que ya se llevó a 
cabo el trabajo (7), y el sistema de archivos reacciona a este mensaje enviando un mensaje de vuelta al 
sheil para desbloquearlo (8). 

La decisión de cuándo es que han llegado suficientes caracteres depende del modo de la terminal. 
En modo canónico se considera que una petición está completa cuando se recibe un código de salto de 
línea, fin de línea o fin de archivo y, a fin de realizar correctamente el procesamiento de las entradas, una 
línea de entrada no puede exceder el tamaño de la cola de entrada. En el modo no canónico una lectura 
puede solicitar un número mucho mayor de caracteres, y es posible que in_ process tenga que transferir 
caracteres más de una vez antes de que se devuelva un mensaje al sistema de archivos para indicar que la 
operación se ha completado. 

Observe que el controlador d la terminal copia los caracteres reales directamente de su propio 
espacio de direcciones al del shell, sin pasar primero por el sistema de archivos. En el caso de E/S por 
bloques, los datos sí pasan por el sistema de archivos para que éste pueda mantener un buffer caché de los 
bloques más recientemente utilizados. Si un bloque solicitado está en el caché, el sistema de archivos 
podrá satisfacer directamente la petición sin tener que realizar E/S de disco. 

En el caso de la E/S de terminal, no tiene sentido tener un caché. Además, una petición del sistema 
de archivos a un controlador en software de disco siempre puede satisfacerse en unos cientos de 
milisegundos, como máximo, por lo que no hay problema si se obliga al sistema de archivos a esperar. La 
E/S de terminal puede tardar horas en completarse, o nunca completarse 
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(en modo canónico la tarea de la terminal espera una línea completa, y también podría tener que esperar 
un tiempo largo en modo no canónico, dependiendo de los valores de MESÍy TIME). Por tanto, no es 
aceptable hacer que el sistema de archivos se bloquee hasta que se haya satisfecho una petición de entrada 
de la terminal. 

Más adelante, puede suceder que el usuario se haya adelantado tecleando, y que los caracteres 
estén disponibles antes de ser solicitados, por haber ocurrido previamente los sucesos 4 y 5. En tal caso, 
los sucesos 1, 2, 6, 7 y 8 ocurrirán en rápida sucesión después de la petición de lectura; el suceso 3 jamás 
ocurrirá. 

Si sucede que la tarea de terminal se está ejecutando cuando ocurre una interrupción de reloj, no 
se le podrá enviar ningún mensaje porque no estará esperando recibirlo. Sin embargo, a fin de mantener 
las entradas y salidas fluyendo continuamente cuando la tarea de la terminal está ocupada, se inspeccionan 
en varios momentos las banderas tty events de todos los dispositivos terminales, por ejemplo, 
inmediatamente después de procesar un mensaje y contestarlo. Por tanto, es posible agregar caracteres a la 
cola de la consola sin la ayuda de un mensaje de despertar enviado por el reloj. Si ocurren dos o más 
interrupciones de reloj antes de que el controlador de la terminal ter mi ne lo que está haciendo, todos los 
caracteres se almacenarán en ibuf, y se encenderá repetidamente tty flags. En última instancia, la tarea de 
la terminal recibe un mensaje; el resto se pierde. Sin embargo, como todos los caracteres están 
almacenados en el buffer, no se pierden entradas tecleadas. Incluso es posible que, para cuando la tarea de 
la terminal recibe un mensaje, la entrada está completa y ya se envió una respuesta al proceso de usuario. 

El problema de qué hacer en un sistema de mensajes sin buffers (principio de cita) cuando una 
rutina de interrupción desea enviar un mensaje a un proceso que está ocupado es inherente a este tipo de 
diseño. En la mayor parte de los dispositivos, como los discos, las interrupciones sólo ocurren como 
respuesta a comandos emitidos por el controlador en software, así que sólo puede haber una interrupción 
pendiente en un momento dado. Los únicos dispositivos que generan interrupciones por sí solos son el 
reloj y las terminales (y, cuando está habilitada, la red). El reloj se maneja contando los fies pendientes, así 
que si la tarea del reloj no recibe un mensaje del manejador de interrupciones del reloj, puede compensarlo 
posteriormente. Las terminales se manejan haciendo que la rutina de interrupciones acumule los caracteres 
en un buffer y encienda una bandera para indicar que se han recibido caracteres. Si la tarea de terminal se 
está ejecutando, examinará todas estas banderas antes de dormirse y no se dormirá si tiene más trabajo que 
hacer. 

La tarea de la terminal no es despertada directamente por interrupciones de terminal debido al 
excesivo gasto extra que ello implicaría. El reloj envía una interrupción a la tarea de la ter mi nal en el 
siguiente tic después de cada interrupción de terminal. Escribiendo 100 palabras por minuto, un 
mecanógrafo teclea menos de 10 caracteres por segundo. Incluso con un mecanógrafo rápido es probable 
que se envíe a la tarea de la terminal un mensaje de interrupción por cada carácter tecleado, aunque podría 
ser que se perdieran algunos de esos mensajes. Si el buffer se llena antes de ser vaciado, los caracteres en 
exceso se desecharán, pero la experiencia muestra que, en el caso de un teclado, basta con un buffer de 32 
caracteres. En el caso de otros dispositivos de entrada pueden encontrarse tasas de datos más altas; un 
puerto en serie conectado a un módem de 28 800 bps puede generar tasas 1000 o más veces más rápidas 
que las de un mecanógrafo. A tales velocidades, el módem podría recibir aproximadamente 48 caracteres 
entre dos fies del reloj, 
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pero si se tiene en cuenta la compresión de datos en el enlace de módem el puerto en serie conectado al 
módem debe poder manejar por lo menos el doble de caracteres. Para las líneas en serie, MINIX 
proporciona un buffer de 1024 caracteres. 

Pensamos que es una lástima que la tarea de la terminal no pueda implementarse sin sacrificar algunos de 
nuestros principios de diseño, pero el método que usamos realiza el trabajo sin aumentar demasiado la 
complejidad del software y sin pérdida de rendimiento. La alternativa obvia, desechar el principio de cita 
y hacer que el sistema guarde en buffers todos los mensajes enviados a destinos que no los están 
esperando, es mucho más complicada y también más lenta. 

Los diseñadores de sistemas reales a menudo enfrentan la decisión de usar el caso general, que es 
elegante todo el tiempo pero un tanto lento, o usar técnicas más sencillas que, por lo regular, son rápidas 
pero que en uno o dos casos requieren un truco para funcionar correctamente. Realmente, la experiencia es 
la única guía para decidir cuál enfoque es mejor en circunstancias específicas. Lampson (1984) y Brooks 
0975) resumen una cantidad considerable de experiencia en el diseño de sistemas operativos. Aunque 
estas referencias son viejas, no dejan de ser clásicas. 

Concluiremos nuestra reseña de las entradas de ter mi nal resumiendo los sucesos que ocurren 
cuando una petición de lectura activa inicialmente la tarea de ter mi nal y cuando ésta se reactiva después 
de recibir entradas del teclado (véase la Fig. 3-38). En el primer caso, cuando llega un mensaje a la tarea 
de ter mi nal solicitando caracteres del teclado, el procedimiento principal, ttytask (línea 11817), invoca 
doread (línea 11891) para manejar la petición. Doread almacena los parámetros de la llamada en la 
entrada correspondiente al teclado en tty table, en caso de que no haya suficientes caracteres en el buffer 
para satisfacer la petición. 

A continuación, do read invoca intransfer (línea 12303) para obtener las entradas que ya estén 
esperando, y luego handleevents (línea 12256), que a su vez invoca kbread (línea 13165) y luego 
inJransfer otra vez, para tratar de obtener unos cuantos caracteres más del flujo de 8 entrada. Kb read 
invoca otros procedimientos varios que no se muestran en la Fig. 3-38 para I Balizar su trabajo. El 
resultado es que todo lo que está inmediatamente disponible se copia al «uario. Si no hay nada disponible, 
no se copia nada. Si in transfer o handle events completan la lectura, se envía un mensaje al sistema de 
archivos una vez que se han transferido todos los cacteres, a fin de que el sistema de archivos pueda 
desbloquear al invocador. Si no se completó la lectura (no hubo caracteres, o no hubo suficientes 
caracteres), do read informa de ello al ¡Materna de archivos, indicándole si debe suspender al invocador 
original o, si se solicitó una lectura no bloqueadora, cancelar la lectura. 

El lado derecho de la Fig. 3-38 resume los sucesos que ocurren cuando se despierta la tarea de 
ktenninal después de una interrupción del teclado. Cuando se teclea un carácter, el procedimiento fe 
interrupción kb hw int (línea 13123) coloca el código de carácter recibido en el buffer del teclado, 
enciende una bandera para indicar que el dispositivo de la consola experimentó un evento, |tuego hace lo 
necesario para que en el siguiente tic del reloj se venza un tiempo de espera. La tarea del reloj envía un 
mensaje a la tarea de la terminal diciéndole que algo sucedió. Al recibir este mensaje, tty task examina las 
banderas de eventos de todos los dispositivos terminales e invoca handleevent para cada dispositivo que 
tiene la bandera izada. En el caso del teclado, handle event invoca kb read e in transfer, tal como se hizo 
al recibirse la petición de lectura original. Los sucesos que se muestran en el lado derecho de la figura 
pueden ocurrir varias veces, hasta que se reciben 
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Figura 3-38. Manejo de entradas en el controlador de terminal. La rama izquierda del árbol se toma 
cuando se va a procesar una petición de lectura de caracteres. La rama derecha se toma cuando se envía al 
controlador un mensaje de "se tecleó un carácter". 


suficientes caracteres para satisfacer la petición aceptada por do read después del primer mensaje del 
sistema de archivos. Si éste trata de iniciar una petición pidiendo más caracteres al mismo dispositivo 
antes de completarse la primera petición, se devolverá un error. Desde luego, cada dispositivo es 
independiente; una petición de lectura a nombre de un usuario en una terminal remota se procesa 
independientemente de una hecha a nombre de un usuario en la consola. 

Las funciones que no se muestran en la Fig. 3-38 y que son invocadas por kbread incluye 
mapkey, que convierte los códigos de tecla (códigos de detección) generados por el hardware en códigos 
ASCII, makebreak, que se mantiene al tanto del estado de las teclas modificadori como CTRLy SF1IFT, e 
in_process, que maneja complicaciones tales como intentos por parte del usuario de retroceder borrando 
entradas tecleadas por equivocación, otros caracteres especíales y opciones disponibles en los diferentes 
modos de entrada. ln_process también invoca echo(línea 12531) para que los caracteres tecleados 
aparezcan en la pantalla. 


Salidas a terminales 


En general, la salida de la consola es más sencilla que la entrada de terminales, porque el sisten operativo 
está en control y no necesita preocuparse por peticiones de salida que lleguen en momento) poco 
propicios. Además, como la consola de MINIX es una pantalla con mapa en la memoria, la salida a ella es 
más sencilla aún. No se requieren interrupciones; el funciona mi ento básico consiste 
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en copiar datos de una región de la memoria a otra. Por otro lado, todos los detalles de controlar la 
pantalla, incluido el manejo de secuencias de escape, corre por cuenta del controlador en software. Como 
hicimos para las entradas del teclado en la sección anterior, rastrearemos los pasos que se siguen para 
enviar caracteres a la pantalla de la consola. Supondremos en este ejemplo que se está escribiendo en la 
pantalla activa; las complicaciones menores causadas por las consolas virtuales se analizarán más 
adelante. 

Cuando un proceso desea exhibir algo, generalmente invoca printf, la cual invoca WRITE para 
enviar un mensaje al sistema de archivos. El mensaje contiene un apuntador a los caracteres por exhibir 
(no los caracteres mismos). A continuación, el sistema de archivos envía un mensaje al controlador de la 
terminal, que obtiene los caracteres y los copia en la RAM de video. La Fig. 3-39 muestra los principales 
procedimientos que intervienen en las salidas. 



Figura 3-39. Principales procedimientos empleados para la salida a terminales. La línea punteada indica 
caracteres copiados directamente en ramqueue por cons write. 


Cuando llega un mensaje a la tarea de la terminal solicitándole que escriba en la pantalla, se 
invoca do write (línea 11964) para almacenar los parámetros en la estructura tty de la consola que 
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está en tty table. Luego se invoca handleevents (la misma función que se llama siempre que se encuentra 
izada la bandera tty events). En cada llamada, esta función invoca las rutinas tanto de entrada como de 
salida para el dispositivo seleccionado en su argumento. En el caso de la pantalla de la consola, esto 
implica que primero se procesarán todas las entradas de teclado que estén esperando. Si hay entradas 
esperando, los caracteres de los que debe hacerse eco se agregan a los que ya estén esperando en la salida. 
Luego se hace una llamada a cons write (línea 13729), el procedimiento de salida para las pantallas con 
mapa en la memoria. Este procedimiento emplea phys copy para copiar bloques de caracteres del proceso 
de usuario a un buffer local, posiblemente repitiendo éste y los siguientes pasos varias veces, ya que al 
buffer local sólo le caben 64 bytes. Cuando se llena el buffer local, cada byte de 8 bits se transfiere a otro 
buffer, ramqueue, que es un arreglo de palabras de 16 bits. Cada segundo byte se llena con el valor actual 
del byte de atributo de la pantalla, que determina los colores de primer y segundo plano y otros atributos. 
Si es posible, los caracteres se transfieren directamente a ramqueue, pero ciertos caracteres, como los de 
control o los que forman parte de secuencias de escape, requieren un manejo especial. El manejo especial 
también es necesario cuando la posición de un carácter en la pantalla excedería la anchura de ésta, o 
cuando ramqueue se llena. En estos casos se invoca outchar (línea 13809) para transferir los caracteres y 
realizar todas las demás acciones pertinentes. Por ejemplo, se invoca scroll screen (línea 13896) cuando 
se recibe un salto de línea mientras se está direccionando la última línea de la pantalla, y parse escape 
maneja los caracteres durante una secuencia de escape. Por lo regular, out char invoca flush (línea 
13951), que copia el contenido de ramqueue en la memoria de la pantalla usando la rutina en lenguaje 
ensamblador memvidcopy. También se invoca flush después de que el último carácter se transfiere a 
ramqueue para asegurarse que se exhiban todas las salidas. El resultado final de flush es ordenar al chip 
controlador de video 6845 que exhiba el cursor en la posición correcta. 


Lógicamente, los bytes obtenidos del proceso de usuario podrían escribirse en la RAM de video, 
uno en cada iteración del ciclo. Sin embargo, es más eficiente acumular los caracteres en ramqueue y 
luego copiar el bloque con una llamada a mem vid copy en el entorno de memoria protegida de los 
procesadores clase Pentium. Resulta interesante que esta técnica se introdujo en las primeras versiones de 
MINIX que se ejecutaba en los procesadores más viejos sin memoria protegida. El precursor de 
mem vid copy resolvía un problema de temporización: en las pantallas antiguas el copiado en la memoria 
de video tenía que efectuarse mientras la pantalla estaba en blanco durante el retrazado vertical del haz del 
CRT para no generar basura visual en toda la pantalla. MINIX ya no ofrece este apoyo para equipo 
obsoleto, pues el precio que se paga en términos de rendimiento es excesivo. Sin embargo, la versión 
moderna de MINIX obtiene otros beneficios de copiar ramqueue como bloque. 


La RAM de video disponible para una consola está delimitada en la estructura consolé por los 
campos c start y c limit. La posición actual del cursor se almacena en los campos c column y c row. La 
coordenada (O, 0) está en la esquina superior izquierda de la pantalla, que es donde el hardware comienza 
a llenar la pantalla. Cada barrido de video comienza en la dirección dada por corg y continúa durante 80 
x 25 caracteres (4000 bytes). En otras palabras, el chip 6845 tómala palabra que está a una distancia c org 
del principio de la RAM de video y exhibe el byte del carácter en la esquina superior izquierda, usando el 
byte de atributo para controlar el color, el 
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parpadeo, etc. Luego, el chip obtiene la siguiente palabra y exhibe el carácter en (1, 0). Este proceso 
continúa hasta llegar a (79, 0), momento en el cual se inicia la segunda línea de la pantalla, en la 
coordenada (O, 1). 


Al arranque de la computadora, la pantalla se despeja, se escriben salidas en la RAM de video 
comenzando en la posición cstart, y se asigna a corg el mismo valor que tiene cstart. Por tanto, la 
primera línea aparece en la línea superior de la pantalla. Cuando es necesario exhibir salidas en una nueva 
línea, sea porque la primera está llena o porque out char detectó un carácter de nueva línea, las salidas se 
escriben en la posición dada por c start más 80. Tarde o temprano se llenan las 25 líneas, y es necesario 
desplazar, haciendo avanzar la pantalla. Algunos programas, como los editores, requieren también 
desplazamiento hacia abajo, cuando el cursor está en la línea superior y es necesario moverse más hacia 
arriba dentro del texto. 


Hay dos formas de manejar el desplazamiento de la pantalla. En el desplazamiento por software, 
el carácter que se exhibirá en la posición (O, 0) siempre está en la primera posición de la memoria de 
video, la palabra O relativa a la posición a la que apunta c start, y se ordena al chip controlador de video 
que exhiba esta posición primero colocando la misma dirección en c_prg. Cuando se debe desplazar la 
pantalla, el contenido de la posición relativa 80 de la RAM de video, el principio de la segunda línea de la 
pantalla, se copia en la posición relativa O, la palabra 81 se copia en la posición relativa 1, y así 
sucesivamente. La secuencia de barrido no cambia, poniendo los datos que están en la posición O de la 
memoria en la posición (0,0) de la pantalla, y parece que la imagen se ha desplazado una línea hacia arriba 
en la pantalla. El costo es que la CPU ha movido 80 x 24 = 1920 palabras. En el desplazamiento por 
hardware los datos no cambian de lugar en la memoria; en lugar de ello, se le ordena al chip controlador 
de video que inicie la exhibición en un punto distinto, por ejemplo, los datos que están en la posición 80. 
La contabilización se efectúa sumando 80 al contenido de c org, guardándolo para referencia futura, y 
escribiendo este valor en el registro correcto del chip controlador de video. Para ello se requiere que el 
chip controlador téngala suficiente inteligencia como para manejar la RAM de video en forma "circular", 
tomando los datos del principio de la RAM (la dirección que está en c start) después de haber llegado al 
final (la dirección que está en c limif), o bien que la RAM de video tenga más capacidad que las 80 00 
2000 palabras necesarias para almacenar una sola pantalla. Los adaptadores de pantalla más viejos 
generalmente tienen una memoria más reducida pero pueden continuar del final al principio y realizar 
desplazamiento por hardware. Los adaptadores más nuevos generalmente tienen mucha más memoria que 
la necesaria para exhibir una sola pantalla de texto, pero los chips controladores no pueden continuar del 
final al principio. Así, un adaptador con 32768 bytes de memoria de pantalla puede contener 204 l ín eas 
completas de 160 bytes cada una, y puede realizar desplazamiento por hardware 179 veces antes de que el 
hecho de no poder continuar del final al principio se convierta en un problema. Tarde o temprano, se 
requerirá una operación de copiado de memoria para transferir los datos de las últimas 24 líneas otra vez a 
la posición O de la memoria de video. Sea cual sea el método empleado, se copia una fila de espacios en 
blanco en la RAM de video para asegurar que la nueva línea en la parte inferior de la pantalla esté vacía. 


Cuando se configuran consolas virtuales, la memoria disponible dentro de un adaptador de video 
se divide equitativamente entre el número de consolas deseadas inicializando debidamente los campos 
c start y climit para cada consola. Esto afecta el desplazamiento de pantalla. En 
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cualquier adaptador con el tamaño suficiente para apoyar consolas virtuales, el desplazamiento por 
software ocurre con cierta frecuencia, incluso si nominalmente está vigente el desplazamiento por 
hardware. Cuanto menor sea la cantidad de memoria disponible para cada pantalla de consola, con mayor 
frecuencia será necesario usar el desplazamiento por software. Se llega al límite cuando se configura el 
número máximo posible de consolas. Entonces, toda operación de desplazamiento tendrá que efectuarse 
por software. 

La posición del cursor relativa al principio de la RAM de video se puede deducir de ccolumn y 
crow, pero es más rápido almacenarla explícitamente (en ccur). Cuando se va a exhibir un carácter, se 
coloca en la RAM de video en la posición c cur, que luego se actualiza, lo mismo que c column. En la 
Fig. 3-40 se resumen los campos de la estructura consolé que afectan la posición actual y el origen de la 
pantalla. 


Campo 

Significado 

c start 

Inicio de la memoria de video para esta consola 

c limit 

Límite de la memoria de video para esta consola 

c column 

Columna actual (0-79) con 0 a la izquierda 

crow 

Fila actual (0-24) con O arriba 

ccur 

Distancia del cursor a partir del principio de la RAM de video 

corg 

Posición en RAM a la que apunta el registro base del 6845 


|Figura 3-40. Campos de la estructura consolé relacionados con la posición actual en la pantalla. 


Los caracteres que afectan la posición del cursor (p. ej., salto de línea, retroceso) se manejan 
ajusfando los valores de c column, c row y c cur. Este trabajo se realiza al final de flush mediante una 
llamada a set_6845, que establece los registros del chip controlador de video. El controlador en software 
de la terminal reconoce secuencias de escape que permiten a los editores de pantalla y otros programas 
interactivos actualizar la pantalla de forma flexible. Las secuencias reconocidas son un subconjunto de un 
estándar ANSÍ y deberán ser suficientes para permitir que muchos programas escritos para otro hardware 
y otros sistemas operativos se trasladen fácilmente a MINIX. Hay dos categorías de secuencias de escape: 
las que nunca contienen un parámetro variable y las que pueden contener parámetros. En la primera 
categoría el único representante reconocido por MINIX es ESC M, que indiza la pantalla a la inversa, 
subiendo el cursor una línea y desplazando la pantalla hacia abajo si el cursor ya está en la primera línea. 
La otra categoría puede tener uno o dos parámetros numéricos. Todas las secuencias de este grupo 
comienzan con ESC [. El "[" es el introductor de la secuencia de control. En la Fig. 3-36 se mostró una 
tabla de las secuencias de escape definidas por el estándar ANSÍ y reconocidas por MINIX. 


El análisis sintáctico de las secuencias d& escape no es trivial. Las secuencias de escape válidas 
en MINIX pueden tener sólo dos caracteres, como en ESC M, o un máximo de ocho caracteres en el caso 
de una secuencia que acepta dos parámetros numéricos, cada uno de los cuales puede 
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tener un valor de dos dígitos, como en ESC [20;60H, que mueve el cursor a la línea 20, columna 60. En 
una secuencia que acepta un parámetro, éste puede omitirse, y en una secuencia que acepta dos parámetros 
puede omitirse cualquiera de ellos, o ambos. Cuando se omite un parámetro o se usa uno que está fuera del 
intervalo válido, se sustituye un valor predeterminado, que es el valor permitido más bajo. 

Considere las siguientes formas de construir una secuencia para llevar el cursor a la esquina 
superior izquierda de la pantalla: 


1. ESC [H es aceptable, porque si no se incluyen parámetros se suponen los parámetros válidos 
más bajos. 

2. ESC [1 ; 1H envía correctamente el cursor a la fila 1 y la columna 1 (con ANSÍ, los números de 
fila y de columna comienzan en 1). 

3. Tanto ESC [1 ;H como ESC [;1H tienen un parámetro omitido, que por omisión es 1 igual que 
en el primer ejemplo. 

4. ESC [0;OH hace lo mismo, pues como ambos parámetros son menores que el valor mínimo 
permitido, se sustituye el mínimo. 


Presentamos estos ejemplos no para sugerir que debemos usar deliberadamente parámetros no, válidos, 
sino para poner de relieve que el código que analiza sintácticamente tales secuencias no es trivial. 


MINIX implementa un autómata de estados finitos para realizar este análisis sintáctico. La 
variable cescstate de la estructura consolé normalmente tiene el valor 0. Cuando out char detecta un 
carácter ESC, cambia c esc state a 1, y los caracteres subsecuentes son procesados por parse e'icape 
(línea 13986). Si el siguiente carácter es el introductor de secuencias de control, se ingresa en el estado 2; 
de lo contrario, se considera que la secuencia está completa y se invoca doescape (línea 14045). En el 
estado 2, en tanto los caracteres que llegan sean numéricos, se calculará un parámetro multiplicando el 
valor anterior del parámetro (que inicialmente es 0) por 10 y sumándole el valor numérico del carácter 
actual. Los valores de los parámetros se guardan en un arreglo, y cuando se detecta un signo de punto y 
coma el procesamiento pasa a la siguiente celda del arreglo. (El arreglo en MINIX sólo tiene dos 
elementos, pero el principio es el mismo.) Cuando se encuentra un carácter no numérico que no es un 
signo de punto y coma se considera que la secuencia está completa, y se vuelve a invocar do escape. El 
carácter vigente en el momento de entrar en do escape se usa para seleccionar exactamente la acción por 
realizar y la forma de interpretar los parámetros, ya sea los predefinidos o los introducidos en el flujo de 
caracteres. Esto se ilustra en la Fig. 3-48. 


Mapas de teclas cargables 


El teclado de IBM PC no genera códigos ASCII directamente. Cada tecla se identifica con un número, 
comenzando por las teclas situadas arriba a la izquierda en el teclado de PC original: 1 para la tecla 
"ESC", 2 para el "I", y así sucesivamente. A cada tecla se asigna un número, 
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incluidas las teclas modificadoras como las teclas SHIFT izquierda y SHIFT derecha, números 42 y 54. 
Cuando se oprime una tecla, MINIX recibe el número de tecla como código de escrutinio o detección. 
También se genera un código de detección cuando se suelta una tecla, pero en este caso el bit más 
significativo es 1 (lo que equivale a sumar 128 al número de tecla). Esto permite distinguir entre la 
pulsación y la liberación de una tecla. Si se sabe cuáles teclas modificadoras se han presionado pero 
todavía no se han soltado, se puede obtener un gran número de combinaciones. Desde luego, para fines 
ordinarios las combinaciones de dos dedos, como SHIFT-A o CTRF-D, son las más fáciles de digitar para 
quienes escriben con las dos manos, pero en ocasiones especiales pueden usarse combinaciones de tres (o 
más) teclas, como CTRE-SHIFT-A o la conocida combinación CTRE-AET-DEF que los usuarios de PC 
reconocen como la forma de restablecer y reiniciar el sistema. 


Fa complejidad del teclado de la PC ofrece una gran flexibilidad de uso. Un teclado estándar tiene 
definidas 47 teclas de caracteres ordinarios (26 alfabéticos, 10 numéricos y 11 de puntuación). Si estamos 
dispuestos a usar combinaciones de teclas modificadoras de tres dedos, como CTRL-AFT-SHIFT, 
podemos reconocer un conjunto de caracteres de 376 (8 x 47) miembros. Esto de ninguna manera es el 
límite de lo posible, pero por ahora supongamos que no nos interesa distinguir entre las teclas 
modificadoras de la mano izquierda y de la derecha, ni usar las teclas de funciones ni las del subteclado 
numérico. De hecho, no estamos limitados a usar sólo las teclas CTRF, AFT y SHIFT como 
modificadores; podríamos retirar algunas teclas del conjunto de teclas ordinarias y usarlas como 
modificadores si quisiéramos escribir un controlador que apoyara tal sistema. 


Eos sistemas operativos que emplean tales teclados se valen de un mapa de teclas para determinar 
qué código de carácter deben pasar a un programa con base en la tecla que se está pulsando y los 
modificadores que están activos. El mapa de teclas de MINIX lógicamente es un arreglo de 128 filas, que 
representan los posibles valores de código de detección (se escogió este tamaño para poder manejar 
teclados japoneses; los teclados estadounidenses y europeos no tienen tantas teclas) y seis columnas. Fas 
columnas representan ningún modificador, la tecla SHIFT, la tecla CTRF, la tecla AFT izquierda, la tecla 
AFT derecha y una combinación de cualquier tecla AFT con la tecla SHIFT. Por tanto, hay 720 ((128-6) x 
6) códigos de carácter que se pueden generar con este esquema si se cuenta con un teclado adecuado. Esto 
requiere que cada entrada de la tabla sea una cantidad de 16 bits. En el caso de los teclados 
estadounidenses, las columnas AFT y AFT2 son idénticas. AFT2 se llama AFTGR en teclados para otros 
idiomas, y muchos de estos mapas de teclas reconocen teclas con tres símbolos usando esta tecla como 
modificador. 

Un mapa de teclas estándar (determinado por la línea 


#include keymaps/us-std.src 

de keyboard.c) se incorpora en el kemel de MINIX en el momento de la compilación, pero se puede usar 
una llamada 

ioctl(0, KIOCSMAP, keymap) 

para cargar un mapa diferente en el kemel en la dirección keymap. Un mapa de teclas completo ocupa 
1536 bytes (128 x 6 x 2). Fos mapas de teclas extra se almacenan en una forma comprimí- 
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da. Se usa un programa llamado genmap para crear un nuevo mapa de teclas comprimido. Una vez 
compilado, genmap incluye el código keymap.src para un mapa de teclas en particular, así que el mapa se 
compila dentro de genmap. Normalmente, genmap se ejecuta inmediatamente después de compilarse, y en 
ese momento escribe la versión comprimida en un archivo y se borra el código binario de genmap. El 
comando loadkeys lee un mapa de teclas comprimido, lo expande internamente, y luego invoca IOCTL 
para transferir el mapa de teclas a la memoria del kemel. MINIX puede ejecutar loadkeys 
automáticamente al iniciarse, y además el usuario puede invocar este programa en el momento que desee. 


Código de detección 

Carácter 

Normal 

SHIFT 

ALT1 

ALT2 

ALT+SHIFT 

CTRL 

00 

ninguno 

0 

0 

0 

0 

0 

0 

01 

ESC 

C(T) 

cm 

CA(T) 

CA(T) 

CA(T) 

C(T) 

02 

’l' 

T 

T 

A(T) 

A('l') 

A(T) 

C('A’) 

13 


V 


A(’=') 

A(V) 

A(V) 

ce®) 

16 

'q‘ 

L('q') 

'Q’ 

A(’q’) 

A('q') 

ACO') 

cea-) 

28 

CR/LF 

C(’M’) 

C('M') 

CA(’M’) 

CA(’M’) 

CA('M') 

C(J-) 

29 

CTRL 

CTRL 

CTRL 

CTRL 

CTRL 

CTRL 

CTRL 

1 59 

F1 

F1 

SF1 

AF1 

AF1 

ASF1 

CF-I 

1 127 

77? 

0 

0 

0 

0 

0 

0 

■r' 


Figura 3-41. Unas cuantas entradas de un archivo fuente de mapa de teclas. 


El código fuente de un mapa de teclas define un arreglo inicializado grande, y a fin de ahorrar 
espacio no se ha imprimido el archivo del mapa de teclas junto con el código fuente. La Fig. 3-41 muestra 
en forma tabular el contenido de unas cuantas líneas de src/kemel/keymaps/usstd.src que ilustran varios 
aspectos de los mapas de teclas. El teclado de la IBM PC no cuenta con una tecla que genere un código de 
detección de 0. La entrada para el código 1, la tecla ESC, muestra que el valor devuelto no se modifica 
cuando se oprimen SHIFT o CTRL, pero sí se devuelve un código distinto cuando se oprime una tecla 
ALT al mismo tiempo que ESC. Los valores compilados en las diferentes colu mn as se determinan 
mediante macros definidas en include/minix/keymap.h: 


#define C(c) 
#defineA(c) 
#define CA(c) 

#define L(c) 
atribute*/ 


((c) & 0x1 F) 

((c) I 0x80) 
A(C(c)) 

((c)l HASCAPS) 


/* Mapear a código de control */ 

/* Encender bit ocho (ALT) */ 

/* CTRL-ALT */ 

/*Agregar atributo de "Bloq Mayús tiene efecto" 


Las primeras tres de estas macros manipulan bits en el código del carácter citado para producir el 
código necesario que se devolverá a la aplicación. La última pone en 1 el bit HASCAPS en el byte alto del 
valor de 16 bits. Éste es una bandera que indica que hay que verificar el estado de la tecla de bloqueo de 
mayúsculas (Caps Lock) y tal vez modificar el código antes de devolverlo. En la figura, las entradas para 
los códigos de detección 2, 13 y 16 muestran la forma como se manejan 
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las teclas numéricas, de puntuación y alfabéticas típicas. En el caso del código 28 se observa una 
característica especial: normalmente la tecla ENTER produce un código CR (OxOD), representado aquí 
por C('M'). Dado que el carácter de nueva línea en los archivos UNIX es el código LF (OxOA), y a veces 
es necesario introducir éste directamente, este mapa del teclado contempla una combinación CTRL- 
ENTER, que produce este código, C(T). 

El código de detección 29 es uno de los códigos modificadores y se le debe reconocer sin importar 
cuál otra tecla esté oprimida, así que se devuelve el valor CTRL aunque esté presionada alguna otra tecla. 
Las teclas de función no devuelven valores ASCII ordinarios, y la fila para el código de detección 59 
muestra simbólicamente los valores (definidos en include/minix/keymap.h) que se devuelven para la tecla 
F1 en combinación con otros modificadores. Estos valores son Fl: 0x0110, SF1: 0x1010, AF1, 0x0810, 
ASF1: OxOClO y CF1: 0x0210. La última entrada que se muestra en la figura, para el código de detección 
127, es representativa de muchas entradas cerca del final del arreglo. En muchos teclados, y ciertamente 
en aquellos que se usan en Europa y América, no hay suficientes teclas para generar todos los códigos 
posibles, y estas entradas de la tabla se llenan con ceros. 


Tipos de letra cargables 


Las primeras PC tenían los valores para generar caracteres en una pantalla de video almacenados 
sólo en ROM, pero las pantallas que se usan en los sistemas modernos cuentan con RAM en los 
adaptadores de video en la que se pueden cargar patrones personalizados de generación de caracteres. Esto 
se maneja en MINIX con una operación 

ioctl(0, TIOCSFON, font) 

de IOCTL. MINIX maneja un modo de video de 80 columnas x 25 filas, y los archivos de tipos de letra 
contienen 4096 bytes. Cada byte representa una línea de 8 pixeles que se iluminan si el valor del bit 
correspondiente es 1, y se necesitan 16 de esas líneas para mapear cada carácter. Sin embargo, el 
adaptador de video emplea 32 bytes para mapear cada carácter, a fin de ofrecer una definición más alta en 
modos que MINIX todavía no reconoce. Se incluye el comando loadfont para convertir estos archivos a la 
estructura font de 8192 bytes a la que hace referencia la llamada [OCTL y para usar dicha llamada con el 
fin de cargar el tipo de letra. Al igual que con los mapas de teclas, se puede cargar un tipo de letra durante 
el arranque, o en cualquier otro momento durante el funciona mi ento normal. Por otro lado, cada adaptador 
de video tiene un tipo de letra incorporado en su ROM que está disponible por omisión. No hay necesidad 
de compilar un tipo de letra en MINIX mismo, y el único apoyo de tipo de letra necesario en el kemel es 
el código para llevar a. cabo la operación IOCTL TIOCSFON. 


3.9.4 Implementación del controlador de terminales independiente del dispositivo 


En esta sección comenzaremos a examinar el código íuente del controlador de terminal con 
detalle. Cuando estudiamos los dispositivos por bloques vimos que varias tareas que apoyan varios 
dispositivos distintos pueden compartir una base de software común. El caso de los dispositivos 
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de terminal es similar, pero con la diferencia de que hay una tarea de terminal que apoya varios tipos 
distintos de dispositivos terminales. Aquí comenzaremos con el código independiente del dispositivo. En 
secciones posteriores examinaremos el código dependiente del dispositivo para el teclado y la pantalla de 
la consola con mapa en la memoria. 


Estructuras de datos de la tarea de terminal 


El archivo tty.h contiene definiciones utilizadas por los archivos en C que implementan los 
controladores de terminal. La mayor parte de las variables declaradas en este archivo se identifican con el 
prefijo tty_. También se declara una de esas variables en glo.h como EXTERN. Se trata de ttytimeout, 
utilizada por los manejadores de interrupciones tanto del reloj como de la terminal. 

Dentro de tty.h, las definiciones de las banderas ONOCTTY y ONONBLOCK (que son 
argumentos opcionales de la llamada OPEN) son duplicados de definiciones contenidas en include/fcntl.h, 
pero se repiten aquí para no tener que incluir otro archivo. Los tipos devfun t y devfunarg t (líneas 11611 
y 11612) sirven para definir apuntadores a funciones, a fin de poder manejar llamadas indirectas usando 
un mecanismo similar al que vimos en el código para el ciclo principal de los controladores de disco. 

La mas importante definición contenida en tty.h es la estructura tty (líneas 11614 a 11668). Hay 
una de estas estructuras para cada dispositivo terminal (la pantalla de la consola y el teclado juntos 
cuentan como una sola terminal). La primera variable de la estructura tty, tty events, es la bandera que se 
enciende cuando una interrupción causa un cambio que requiere que la tarea de la terminal atienda el 
dispositivo. Cuando se enciende esta bandera, también se manipula la variable global tty timeout para 
indicarle al manejador de interrupciones del reloj que debe despertar a la tarea de la terminal en el 
siguiente tic del reloj. 

El resto de la estructura tty se organiza de modo tal que se agrupen las variables que se ocupan de 
entradas, salidas, estado e información referente a operaciones incompletas. En la sección de entrada, 
tty inhead y tty intail definen la cola que se usa como buffer para los caracteres recibidos. Tty incount 
cuenta el número de caracteres contenidos en esta cola, y fty eotct cuenta líneas o caracteres, como se 
explica más adelante. Todas las llamadas específicas para un dispositivo se realizan indirectamente, con 
excepción de las rutinas que inicializan las terminales, que se invocan para establecer los apuntadores 
empleados en las llamadas indirectas. Los campos tty devread y tty icancel contienen apuntadores a 
código específico para cada dispositivo que realizan las operaciones de lectura y de cancelación de 
entradas. Ttymin se usa en comparaciones con ttyeotet. Cuando esta última se vuelve igual a la primera, 
es que se completó una operación de entrada. Durante las entradas canónicas, tty min se hace igual a 1 y 
tty eotet cuenta las líneas introducidas. Durante la entrada no canónica, tty eotet cuenta caracteres y a tty 
rnin se asigna el contenido del campo MIN de la estructura tennios. Así, la comparación de las dos 
variables indica cuándo está lista una línea o cuándo se llega a la cuenta mí nim a de caracteres, 
dependiendo del modo. 

Ttytime contiene el valor de temporizador que determina cuándo el manejador de interrupciones 
del reloj debe despertar a la tarea de la terminal, y tty timenext es un apuntador empleado para encadenar 
los campos tty time activos formando una lista enlazada. La lista se ordena cada 
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vez que se establece un temporizado!", así que el manejador de interrupciones sólo tiene que ver la 
primera entrada. MINIX puede apoyar muchas terminales remotas, de las cuales sólo unas cuantas podrían 
tener temporizadores establecidos en un momento dado. La lista de temporizadores activos hace que el 
trabajo del manejador del reloj sea más fácil de lo que sena si tuviera que examinar cada entrada de 
ttytable. 

Dado que la puesta en cola de las salidas corre por cuenta del código específico para cada 
dispositivo, la sección de salida de tty no declara variables y consiste exclusivamente en apuntadores a 
funciones específicas para cada dispositivo que escriben, hacen eco, envían una señal de paro y cancelan 
salidas. En la sección de estado, las banderas tty reprint, ttyescaped y tty inhibited indican que el último 
carácter detectado tiene un significado especial; por ejemplo, cuando se detecta un carácter CTRL-V 
(LNEXT), se asigna 1 a tty escaped para indicar que se debe hacer caso omiso de cualquier significado 
especial que pudiera tener el siguiente carácter. 

La siguiente parte de la estructura contiene datos relativos a las operaciones DEV READ, 
DEV WRITE y DEVIOCTL que se están efectuando. Dos procesos participan en cada una de estas 
operaciones. El servidor que administra la llamada al sistema (normalmente FS), se identifica en 
ttyincaller (línea 11644). El servidor invoca la tarea de terminal a nombre de otro proceso que necesita 
realizar una operación de E/S, y este cliente se identifica en tty inproc (línea 11645). Tal como se 
describió en la Fig. 3-37, durante un READ, los caracteres se transfieren directamente de la tarea de 
terminal a un buffer dentro del espacio de memoria del invocador original. TtyJnproc y tty in vir ubican 
este buffer. Las dos variables siguientes, tty inleft y tty incum, cuentan los caracteres que todavía se 
necesitan y los que ya se transfirieron. Se requieren conjuntos similares de variables para una llamada al 
sistema WRITE. En el caso de IOCTL, puede haber una transferencia inmediata de datos entre el proceso 
solicitante y la tarea, por lo que se necesita una dirección virtual, pero no son necesarias variables para 
marcar el avance de una operación. Una petición IOCTL podría posponerse, por ejemplo, hasta que se 
completen las salidas en curso, pero en el momento oportuno la petición se llevará a cabo en una sola 
operación. Por último, la estructura tty incluye algunas variables que no pertenecen a ninguna otra 
categoría, incluidos apuntadores a las fúnciones que manejan las operaciones DEV IOCTL y 
DEV CLOSE en el nivel de dispositivo, una estructura termios al estilo POSIX y una estructura winsize 
que proporciona apoyo a las pantallas orientadas a ventanas. La última parte de la estructura sirve para 
almacenar la cola de entrada misma en el arreglo tty inbuf. Cabe señalar que éste es un arreglo de ul6_t, 
no de caracteres char de 8 bits. Aunque las aplicaciones y dispositivos usen códigos de 8 bits para los 
caracteres, el lenguaje C requiere que la función de entrada getchar trabaje con un tipo de datos más 
grande a fin de poder devolver un valor EOF simbólico además de los 256 valores de byte posibles. 

La tabla tty table, un arreglo de estructuras tty, se declara usando la macro EXTERN (lina 
11670). Hay un elemento para cada terminal habilitada por las definiciones NR CONS, NR RS LINES y 
NR PTYS de include/minix/config.h. Para la configuración que estudiamos este libro, se habilitan dos 
consolas, pero se puede recompilar MINIX para agregar hasta dos líneas en serie y hasta 64 
seudoterminales. 

Hay otra definición EXTERN en tty.h. Ttytimelist (línea 11690) es un apuntador que 
temporizador usa para contener la cabeza de la lista enlazada de campos ttyJtime. El archivo cabecera 
tty.h se incluye en muchos archivos, y la memoria para tty table y ltytimelist se asi 
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durante la compilación de table.c, de la misma manera que las variables EXTERN que se definen en el 
archivo de cabecera glo.h. 

Al final de tty.h se definen dos macros, buflen y bufend. Éstas se utilizan a menudo en el código 
de la tarea de terminal, que copia muchos datos de y en buffers. 


El controlador de terminal independiente del dispositivo 


La tarea de terminal principal y todas las funciones de apoyo independientes del dispositivo están 
en tty.c. Puesto que la tarea apoya muchos dispositivos distintos, se deben usar los números de dispositivo 
secundarios para distinguir cuál dispositivo se está apoyando en una llamada en particular, y dichos 
números se definen en las líneas 11760 a 11764. Después vienen varias definiciones de macros. Si un 
dispositivo no está inicializado, los apuntadores a las fúnciones específicas para ese dispositivo contienen 
ceros, colocados ahí por el compilador de C. Esto permite definir la macro tty active (línea 11774) que 
devuelve FALSE si encuentra un apuntador nulo. Desde luego, no es posible acceder indirectamente al 
código de inicialización de un dispositivo si parte de su trabajo consiste en inicializar los apuntadores que 
hacen posible el acceso indirecto. Las líneas 11777 a 11783 contienen definiciones de macros 
condicionales que igualan las llamadas de inicialización para dispositivos RS-232 o de seudoterminal a 
una fúnción nula cuando estos dispositivos no están configurados. En esta sección se puede inhabilitar 
do pty de forma similar. Esto permite omitir por completo el código para estos dispositivos si no se 
necesita. 

Puesto que hay un gran número de parámetros configurables para cada terminal, y puede haber 
muchas terminales en un sistema conectado en red, se declara una estructura termios defaults y se 
inicializa con valores por omisión (todos los cuales se definen en include/termios.h) en las líneas 11803 a 
11810. Esta estructura se copia en la entrada de tty table para una terminal cada vez que es necesario 
inicializarla o reinicializarla. Los valores por omisión para los caracteres especiales se mostraron en la Fig. 
3-33. En la Fig. 3-42 se muestran los valores por omisión para las diversas banderas. En la siguiente línea 
se declara de forma similar la estructura winsize defaults y se deja que el compilador de C la inicialice 
con solamente ceros. Ésta es la acción por omisión apropiada; está diciendo "se desconoce el tamaño de la 
ventana, úsese /etc/termcap". 


Campo 

Valores por omisión 

ciflag 

BRKINT ICRNL IXON IXANY 

coflag 

OPOST ONLCR 

ccflag 

CREAD CS 8 HUPCL 

ciflag 

ISIG IEXTEN ICANON ECHO ECHOE 


Figura 3-42. Valores por omisión de las banderas de termios. 

El punto de entrada para la tarea de terminal es tty task (línea 11817). Antes de entrar en el oiclo 
principal, se invoca tty init para cada terminal configurada (en el ciclo de la línea 11826), y 
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luego se exhibe el mensaje de inicio de MESÍIX (líneas 11829 a 11831). Aunque el código fuente muestra 
una llamada a printf, cuando se compila este código está activa la macro que conviene las llamadas a la 
rutina de biblioteca printf en llamadas a printk. Printk usa una rutina llamada putk dentro del controlador 
de la consola, así que no interviene el sistema de archivos. Este mensaje sólo se envía a la pantalla de la 
consola primaria y no puede redirigirse. 


El ciclo principal de las líneas 11833 a 11884 es, en principio, igual al ciclo principal cualquier 
tarea; recibe un mensaje, ejecuta un switch con el tipo de mensaje para invocar la función apropiada, y 
luego genera un mensaje de retomo. Sin embargo, hay algunas complicación. Primero, una buena parte del 
trabajo es realizada por rutinas de interrupción de bajo nivel, sobre todo al manejar las entradas de la 
terminal. En la sección anterior vimos que se aceptan caractes individuales del teclado y se colocan en un 
buffer sin enviar un mensaje a la tarea de ter mi nal por cada carácter. Por tanto, antes de intentar recibir un 
mensaje, el ciclo principal siempre recorre toda la ttytable, inspeccionando la bandera tp->tty_events de 
cada terminal e invocando handle events si es necesario (líneas 11835 a 11837) para ocuparse de todos 
los asuntos inconclusos. Sólo si no hay nada que exija atención inmediata se efectúa una llamada a 
RECEIVE. Si el mensaje recibido proviene del hardware, un enunciado continué permite reiniciar de 
inmediato el ciclo y volver a comprobar si han ocurrido eventos. 


Segundo, esta tarea da servicio a varios dispositivos. Si un mensaje recibido proviene de una 
interrupción de hardware, se identifica el dispositivo o dispositivos que necesitan servicio examinando las 
banderas tp->tty_events. Si la interrupción no es de hardware, se usa el campo TTY LINE del mensaje 
para determinar cuál dispositivo debe responder al mensaje. El número de dispositivo secundario se 
descodifica mediante una serie de comparaciones que permiten hacer que tp apunte a la entrada correcta 
de tty table (líneas 11845 a 11864). Si el dispositivo es una seudoterminal, se invoca do_pty (enpty.c) y 
se reinicia el ciclo principal. En este caso do_pty genera el mensaje de respuesta. Desde luego, si no están 
habilitadas las seudoterminales, la llamada a do_pty usa la macro ficticia que se definió antes. Es de 
esperar que no ocurrirán intentos de acceder a dispositivos inexistentes, pero siempre es más fácil agregar 
otra verificación que comprobar que no haya errores en alguna otra parte del sistema. Si el dispositivo no 
existe o no está configurado, se genera un mensaje de respuesta con el mensaje de error ENXIO y, una vez 
más, el control regresa al inicio del ciclo. 


El resto de la tarea se parece a lo que hemos visto en el ciclo principal de otras tareas, un switch 
con base en el tipo de mensaje (líneas 11874 a 11883). Se invoca la fúnción apropiada para el tipo de 
petición, doread, dowrite, etc. En cada caso la función invocada genera el mensaje de respuesta, en 
lugar de devolver al ciclo principal la información necesaria para construir el mensaje. Sólo se genera un 
mensaje de respuesta al final del ciclo principal si no se recibió un tipo de mensaje válido. En tal caso se 
envía un mensaje de error EINVAL. En vista de que se envían mensajes de respuesta desde muchos 
lugares distintos dentro de la tarea de terminal, se invoca una rutina común, tty reply, para que se 
encargue de los detalles de la construcción de los mensajes de respuesta. 

Si el mensaje recibido por tty task es de un tipo válido, no el resultado de una interrupción, y no 
proviene de una seudoterminal, el switch al final del ciclo principal invoca una de las funciones do read, 
do write, doJ.ocñ, do open, do close o do cancel. Los argumentos de todas estas lia- 
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madas son tp, un apuntador a una estructura tty y la dirección del mensaje. Antes de examinar cada 
función, mencionaremos unas cuantas consideraciones generales. Dado que tty task puede dar servicio a 
múltiples dispositivos de terminal, estas funciones deben regresar rápidamente para que el ciclo principal 
pueda continuar. Sin embargo, cabe la posibilidad de que doread, do write y doJocti no puedan 
completar inmediatamente todo el trabajo solicitado. A fin de que el sistema de archivos (FS) pueda 
atender otras llamadas, se requiere una respuesta inmediata. Si la petición no puede llevarse a cabo de 
inmediato, se devuelve el código SUSPEND en el campo de estado del mensaje de respuesta. Esto 
corresponde al mensaje marcado con (3) en la Fig. 3-37 y suspende el proceso que inició la llamada, al 
tiempo que desbloquea FS. Los mensajes correspondientes a (7) y (8) en la figura se enviarán 
posteriormente cuando la operación pueda completarse. Si la petición puede satisfacerse plenamente, o si 
ocurre un error, se devuelve la cuenta de bytes trans- feridos o bien el código de error en el campo de 
estado del mensaje de retomo al FS. En este caso el FS enviará un mensaje inmediatamente al proceso que 
efectuó la llamada original, para despertarlo. 


La lectura de una terminal es fundamentalmente diferente de la lectura de un dispositivo de disco. 
El controlador en software del disco emite un comando al hardware del disco y tarde o temprano recibe 
datos, a menos que haya habido una falla mecánica o eléctrica. La computadora puede exhibir una 
indicación en la pantalla, pero no tiene manera de obligar a la persona que está sentada ante la terminal a 
que comience a teclear. De hecho, no hay garantía de que habrá una persona sentada ahí. A fin de efectuar 
el pronto regreso que se exige, do read (línea 11891) comienza por almacenar información que permitirá 
completar la petición posteriormente, cuando lleguen las entradas, si es que llegan. Primero se deben 
verificar algunos errores. Es un error que el dispositivo todavía esté esperando entradas para satisfacer una 
petición anterior, o que los parámetros del mensaje no sean válidos (líneas 11901 a 11908). Si se pasan 
estas pruebas, la ; información referente a la petición se copia en los campos apropiados de la entrada tp- 
>tty_table I correspondiente al dispositivo en las líneas 11911 a 11915. El último paso, asignar a. tp- 
>tty_inleft I tí número de caracteres solicitado, es importante. Esta variable sirve para determinar si ya se | 
satisfizo la petición de lectura. En modo canónico tp->tty_inleft se decrementa en uno por cada ' carácter 
devuelto hasta recibir un final de línea; momento en el cual la variable se pone en cero de inmediato. En 
modo no canónico el manejo es diferente, pero la variable también se pone en cero en el momento en que 
la llamada se satisface, sea por vencimiento de un tiempo de espera o por la recepción de cuando menos el 
número mínimo de bytes solicitados. Cuando tp->tty_inleft llega a cero, se envía un mensaje de respuesta. 
Como veremos, los mensajes de respuesta se pueden generar en varios lugares. A veces es necesario 
verificar si un proceso de lectura todavía espera una respuesta; un valor de tp->tty_inleft distinto de cero 
sirve como bandera para este fin. 


En modo canónico un dispositivo terminal espera entradas hasta haber recibido el número de 
caracteres solicitado en la llamada o hasta llegar al final de una línea o del archivo. En la línea 11917 se 
prueba el bit ICANON de la estructura termios para ver si está vigente el modo canónico para la terminal. 
Si dicho bit no es 1, se examinan los valores MIN y TIME de termios para determinar qué acción debe 
emprenderse. 


En la Fig. 3-35 vimos cómo interactúan MIN y TIME para determinar los diferentes 
comportamientos de una llamada de lectura. TIME se prueba en la línea 11918. Un valor de cero corres- 
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ponde a la columna de la izquierda de la Fig. 3-35, y en este caso no se requieren pruebas adicionales aquí. 
Si TIME es distinto de cero, se prueba MIN. Si MIN es cero, se invoca settimer para poner en marcha el 
temporizador que terminará la petición DEVREAD después de un retraso, incluso si no se han recibido 
bytes. Aquí se pone tp->tty_min en 1 para que la llamada termine de inmediato si se reciben uno o más 
bytes antes de vencerse el tiempo de espera. En este punto todavía no se ha verificado la posibilidad de 
que haya entradas, así que varios caracteres podrían estar esperando ya para satisfacer la petición. En tal 
caso se devolverán tantos caracteres como estén listos, hasta el número especificado en la llamada READ, 
tan pronto como se encuentren las entradas. Si tanto TIME como MIN son distintos de cero, el 
temporizador tendrá otro significado. En este caso el temporizador se usa como temporizador entre 
caracteres; se pone en marcha solo después de recibirse el primer carácter y se reinicia después de cada 
carácter subsecuente. Tp—>tty_eotct cuenta caracteres en el modo no canónico, y si es cero en la línea 
11931 querrá decir que todavía no se han recibido caracteres y que el temporizador entre bytes está 
inhibido. Se usan lock y unlock para proteger estas dos llamadas a settimer, a fin de impedir las 
interrupciones de reloj mi entras se está ejecutando settimer. 


De cualquier modo, en la línea 11941 se invoca intransfer para transferir cualesquier bytes que 
estén ya en la cola de entrada directamente al proceso lector. A continuación hay una llamada a 
handleevents, que puede colocar más datos en la cola de entrada y que invoca otra vez a in transfer. Esta 
aparente duplicación de llamadas requiere una explicación. Aunque hasta ahora nuestra descripción ha 
sido en términos de entradas del teclado, doread está en la parte código independiente del dispositivo y 
también da servicio a entradas de terminales remotas conectadas mediante líneas en serie. Es posible que 
entradas previas hayan llenado el buffer de entrada RS-232 a tal punto que se han inhibido las entradas. La 
primera llamada a in transfer no reinicia el flujo, pero la llamada a handle events puede tener este efecto. 
El hecho de que a continuación cause una segunda llamada a in transfer es sólo algo extra; lo importante 
es asegurarse de que la terminal remota pueda transmitir otra vez. Cualquiera de estas llamadas puede 
lograr que se satisfaga la petición y que se envíe el mensaje de respuesta al FS. Se usa tp->tty_inleft como 
bandera para determinar si ya se envió la respuesta; si todavía es distinta de cero en la línea 11944, 
do reaá genera y envía ella misma el mensaje de respuesta. Esto se hace en las líneas 11949 a 11957. Si la 
petición original especificó una lectura no bloqueadora, se le indica al FS que devuelva un código de error 
EAGAIN al invocador original. Si la llamada es una lectura bloqueadora ordinaria, el FS recibirá un 
código SUSPEND que lo desbloqueará, pero indicándole que deje bloqueado al invocador original. En 
este caso se asigna el valor REVIVE al campo tp->tty_inrepcode de la terminal. Cuando se satisfaga 
posteriormente la llamada READ, si es que se hace, este código se colocará en el mensaje de respuesta al 
FS para indicarle que el invocador original se puso a dormir y que se le debe revivir. 


Do write (línea 11964) es similar a do read, pero más sencilla, porque hay menos opciones por 
las cuales preocuparse al manejar una llamada al sistema WRITE. Se realizan verificaciones similares a 
las que do read efectúa, para comprobar que no se esté efectuando todavía una escritura previa y que los 
parámetros del mensaje sean válidos, y luego se copian los parámetros de la petición en la estructura tty. 
Luego se invoca handle events, y se verifica tp->tty_outleft para ver si se realizó el trabajo (líneas 11991 
y 11992). Si fúe así, handle events ya envió un mensaje de 
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respuesta y no falta nada que hacer. Si no, se genera un mensaje de respuesta cuyos parámetros dependen 
de si la llamada WRITE original se hizo en modo bloqueador o no. 


Función de POSIX 

Operación de POSIX 

Tipo de IOCTL 

Parámetro de IOCTL 

tcdrain 

(ninguna) 

TCDRAIN 

(ninguno) 

tcflow 

TCOOFF 

TCFLOW 

int=TCOOFF 

tcflow 

TCOON 

TCFLOW 

int=TCOON 

tcflow 

TCIOFF 

TCFLOW 

int=TCIOFF 

tcflow 

TCION 

TCFLOW 

int=TCION 

tcflush 

TCIFLUSH 

TCFLSH 

int=TCIFLUSH 

tcflush 

TCOFLUSH 

TCFLSH 

int=TCOFLU SH 

tcflush 

TCIOFLUSH 

TCFLSH 

int=TCIOFLUSH 

tcgetattr 

(ninguna) 

TCGETS 

termios 

tcsetattr 

TCSANOW 

TCGETS 

termios 

tcsetattr 

TCSADRAIN 

TCSETSF 

termios 

tcsetattr 

TCSAFLUSH 

TCSETSF 

termios 

tcsendbreak 

(ninguna) 

TCSBRK 

int=duration 


Figura 3-43. Llamadas de POSIX y operaciones IOCTL. 


La siguiente función, doioctl (línea 12012), es larga, pero no difícil de entender. El cuerpo de 
doioctl consiste en dos enunciados switch. El primero determina el tamaño del parámetro al que apunta 
el apuntador del mensaje de petición (líneas 12033 a 12064). Si el tamaño no es cero, se prueba la validez 
del parámetro. No es posible probar el contenido aquí, pero lo que sí puede probarse es si una estructura 
del tamaño requerido, comenzando en la dirección especificada, cabe en el segmento en el que se 
especificó que debía estar. El resto de la función es otro switch basado en el tipo de la operación IOCTL 
solicitada (líneas 12075 a 12161). Desafortunadamente, la decisión de apoyar las operaciones exigidas por 
POSIX con la llamada IOCTL implicó la necesidad de inventar nombres para las operaciones IOCTL que 
sugirieran, pero no duplicaran, los nombres requeridos por POSIX. En la Fig. 3-43 se muestra la relación 
entre los nombres de petición POSIX y los nombres empleados por la llamada IOCTL de MINIX. Una 
operación TCGETS da servicio a una llamada tcgetattr hecha por el usuario y simplemente devuelve una 
copia de la estructura tp—>tty_termios del dispositivo terminal. Los siguientes cuatro tipos de petición 
comparten código. Los tipos de petición TCSETSW, TCSETSF y TCSETS corresponden a llamadas del 
usuario a la función tcsetattr definida por POSIX, y todas realizan la acción básica de copiar una nueva 
estructura termios en la estructura tty de una terminal. El copiado se realiza de inmediato en el caso de las 
llamadas TCSETS y puede efectuarse para las llamadas TCSETSW y TCSETSF si se completaron las 
salidas, mediante una llamada a phys copy, para obtener los datos del usuario, 
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seguida de una llamada a setattr, en las líneas 12098 y 12099. Si tcsetattr se invocó con un modificador 
que solicita posponer la acción hasta completarse las salidas actuales, los parámetros de la petición se 
colocan en la estructura tty de la terminal para ser procesados posteriormente si la prueba de tp— 
>tty_outleft de la línea 12084 revela que no se han completado las salidas. Tcdrain suspende un programa 
hasta completarse las salidas y se traduce a una llamada IOCTL de tipo TCDRAIN. Si ya se completaron 
las salidas, la función no tiene más que hacer; si no, también debe dejar información en la estructura tty. 


La función tcflush de POSIX desecha las entradas no leídas y/o los datos de salida no enviados, 
según su argumento, y la traducción a IOCTL es directa, pues consiste en una llamada a la función 
tty icancel que da servicio a todas las terminales y/o a la función específica para el dispositivo a la que 
apunta tp->tty_icancel (líneas 12102 a 12109). Tcflow se traduce de forma igualmente directa a una 
llamada IOCTL. Para suspender o reiniciar las salidas, esta función coloca un valor TRUE o FALSE en 
tp->tty_inhibited y luego enciende la bandera tp->tty_events. Para suspender o reiniciar las salidas, tcflow 
envía el código STOP (normalmente CTRL-S) o START (CTRL-Q) apropiado a la terminal remota, 
usando la rutina de eco específica para el dispositivo a la que apunta tp->tty_echo (líneas 12120 a 12125). 


Casi todas las demás operaciones de las que doioctl se encarga se efectúan con una línea de 
código, invocando la función apropiada. En los casos de las operaciones KIOCSMAP (cargar mapa de 
teclas) y TIOCSFON (cargar tipo de letra), se realiza una prueba para asegurarse de que el dispositivo 
realmente es una consola, ya que estas operaciones no aplican a otras terminales. Si se están usando 
terminales virtuales, el mismo mapa de teclas y tipo de letra aplican a todas las consolas; el hardware no 
ofrece una forma sencilla de modificar esto. Las operaciones de tamaño de ventana copian una estructura 
winsize entre el proceso de usuario y la tarea de terminal. No obstante, tome nota del comentario que está 
bajo el código para la operación TIOCSWINSZ. Cuando un proceso cambia su tamaño de ventana, en 
algunas versiones de UNIX se supone que el kemel enviará una señal SIGWINCH al grupo de procesos. 
El estándar POSIX no exige dicha señal, pero si usted piensa emplear esas estructuras considere la adición 
de código aquí para iniciar la señal. 


Los últimos dos casos en do ioctl apoyan las funciones tcgetpgrp y tcsetpgrp requeridas por 
POSIX. En estos casos no hay una acción asociada, y siempre se devuelve un error. Esto nada tiene de 
malo. Estas funciones apoyan el control de trabajos, la capacidad para suspender y reiniciar un proceso 
desde el teclado. POSIX no exige control de trabajos, y MINIX no lo apoya. No obstante, POSIX requiere 
dichas funciones, aunque no se apoye el control de trabajos, para asegurar la transportabilidad de los 
programas. 


Do open (línea 12171) realiza una acción básica sencilla: incrementa la variable tp->tty_openct 
para el dispositivo a fin de poder verificar que está abierto. Sin embargo, antes hay que realizar ciertas 
pruebas. POSIX especifica que, en el caso de las terminales ordinarias, el primer proceso que abre una 
terminal es el líder de sesión, y cuando un líder de sesión muere, se revoca el acceso a la terminal por 
parte de los demás procesos de su grupo. Los demonios deben tener la posibilidad de escribir mensajes de 
error, y si su salida de error no se redirige a un archivo, deberá enviarse a un dispositivo de exhibición que 
no pueda cerrarse. Éste es el propósito del dispositivo llamado /dev/log de MINIX. Físicamente, éste es el 
mismo dispositivo que/dev/console, pero se le direcciona 
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empleando un número de dispositivo secundario diferente y se le trata de otra manera. Se trata de un 
dispositivo sólo de escritura, así que doopen devuelve un error EACCESS si se intenta abrirlo para 
lectura (línea 12183). La otra prueba que do open realiza es verificar la bandera O NOCTTY. Si la 
bandera está en O y el dispositivo no es /dev/log, la terminal se convierte en la terminal controladora de 
un grupo de procesos. Esto se hace colocando el número de proceso del invocador en el campo tp- 
>tty_pgrp de la entrada correspondiente de tty table. Después de esto, se incrementa la variable tp- 
>tty_opcnct y se envía el mensaje de respuesta. 

Es posible abrir más de una vez un dispositivo terminal, y la siguiente fúnción, do close (línea 
12198) no tiene otra cosa que hacer más que decrementar tp->tty_openct. La prueba de la línea 12204 
frustra un intento por cerrar el dispositivo si éste es /dev/log. Si esta operación es la última de cierre, se 
cancelan las entradas invocando tp->tty_icancel. También se invocan las rutinas específicas para el 
dispositivo a las que apuntan tp->tty_ocancel y tp->tty_close. Luego se restablecen a sus valores 
predeterminados diversos campos de la estructura tty para el dispositivo y se envía el mensaje de 
respuesta. 

El último manejador de un tipo de mensajes es do cancel (línea 12220), el cual se invoca cuando 
se recibe una señal para un proceso que está bloqueado tratando de leer o escribir. Hay tres estados que 
deben verificarse: 


1. El proceso puede haber estado leyendo cuando se le obligó a terminar. 

2. El proceso puede haber estado escribiendo cuando se le obligó a terminar. 

3. El proceso puede haber sido suspendido por tcdrain hasta completarse sus salidas. 


Se prueba cada uno de estos casos y se invoca la rutina general tp->tty_icancel o bien la rutina 
específica para el dispositivo a la que apunta tp—>tty_ocancel, según sea necesario. En el segundo caso la 
única acción requerida es poner en O la bandera tp->tty_ioreq, para indicar que ya se completó la 
operación IOCTL. Por último, se pone en 1 la bandera tp->tty_events y se envía un mensaje de respuesta. 


Código de apoyo del controlador de terminal 


Habiendo examinado las fruiciones de nivel superior invocadas en el ciclo principal de tty task, ha 
llegado el momento de estudiar el código que las apoya. Comenzaremos con handleevents (línea 12256). 
Como ya se mencionó, en cada repetición del ciclo principal de la tarea de terminal se examina la bandera 
tp->tty_events para cada dispositivo terminal y se invoca handle events si la bandera indica que una 
term in al dada requiere atención. Do read y do write también invocan handle events. Esta rutina debe 
trabajar con rapidez; pone en cero la bandera tp->tty_events y luego invoca rutinas específicas para cada 
dispositivo para leer y escribir, usando los apuntadores a las fruiciones tp->tty_devread y tp->tty_devwrite 
(líneas 12279 a 12282). Éstas se invocan mcondicionalmente, porque no hay forma de probar si fue una 
lectura o una escritura lo que 
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causó que se izara la bandera. Aquí se tomó una decisión de diseño, pues examinar dos banderas para cada 
dispositivo sería más costoso que hacer dos llamadas cada vez que un dispositivo está activo. Además, 
casi siempre que se recibe un carácter de una ter mi nal se debe hacer eco de él, y en tal caso son necesarias 
ambas llamadas. Como se apuntó en la explicación del manejo de las llamadas tcsetattr por do ioctl, 
POSIX puede posponer las operaciones de control en los dispositivos hasta completarse las salidas 
actuales, así que el momento inmediatamente posterior a la invocación de la función tty devwrite 
específica para el dispositivo es ideal para ocuparse de las operaciones de control de E/S. Esto se hace en 
la línea 12285, donde se invoca devioctl si hay una petición de control pendiente. 


Puesto que la bandera tp->tty_events es izada por interrupciones, y podría ser que llegaran 
caracteres en un flujo precipitado desde un dispositivo rápido, cabe la posibilidad de que, para cuando se 
hayan completado dev ioctl y las llamadas a las rutinas de lectura y escritura específicas para el 
dispositivo, otra interrupción haya izado la bandera de nuevo. Es muy importante que las entradas se 
transfieran del buffer donde la rutina de interrupción las colocó inicialmente; por tanto, handle events 
repite las llamadas a las rutinas específicas para el dispositivo en tanto se detecte que la bandera tp- 
>tty_events está izada al final del ciclo (línea 12286). Cuando se detiene el flujo de entrada (también 
podría ser de salida, pero es más probable que sean entradas las que efectúen semejantes demandas 
repetidas), se invoca intransfer para transferir caracteres de la cola de entrada al buffer dentro del proceso 
que solicitó una operación de lectura. In transfer misma envía un mensaje de respuesta si la transferencia 
completa la petición, ya sea transfiriendo el número máximo de caracteres solicitados o llegando al final 
de una línea (en modo canónico). En este caso, tp->tty_left será cero en el regreso a handle e venís. Aquí 
se efectúa una prueba adicional y se envía un mensaje de respuesta si el número de caracteres transferidos 
llegó al número mínimo solicitado. La prueba de tp->tty_inleft evita el envío de un mensaje repetido. 


A continuación examinaremos in transfer (línea 12303), que se encarga de transferir datos de la 
cola de entrada en el espacio de memoria de la tarea al buffer del proceso de usuario que solicitó las 
entradas. Sin embargo, no es posible realizar un copiado de bloque directo. La cola de entrada es un buffer 
circular y es preciso revisar los caracteres para determinar que no se llegó al fin del archivo o, si está 
vigente el modo canónico, que la transferencia sólo continúe hasta el final de una línea. Además, la cola 
de entrada contiene cantidades de 16 bits, pero el buffer del destinatario es un arreglo de caracteres de 8 
bits. Por ello, se emplea un buffer local intermedio. Los caracteres se revisan uno por uno en el momento 
de colocarse en el buffer local y, cuando éste se llena o cuando se ha vaciado la cola de entrada, se invoca 
phys copy para transferir el contenido del buffer local al buffer del proceso receptor (líneas 12319 a 
12345). 


Se usan tres variables de la estructura tty, tp->tty_inleft, tp->tty_eotct y tp->tty_min, para decidir 
si in transfer tiene trabajo que hacer o no, y las dos primeras controlan su ciclo principal. Como se 
mencionó antes, inicialmente se asigna a tp->tty_inleft un valor igual al número de caracteres solicitados 
por una llamada READ. Normalmente, esta variable se decrementa en uno cada vez que se transfiere un 
carácter, pero puede disminuirse a cero abruptamente si se detecta, una condición que indique el final de 
las entradas. Cada vez que tp—>tty_inleft llega a cero, se genera un mensaje de respuesta para el lector, 
así que la variable también cumple su función como bandera para indicar si se ha enviado o no un 
mensaje. Por tanto, en la prueba de la línea 12314,. 
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detectar que tp->tty_inleft vale cero es suficiente razón para abortar la ejecución de intransfer sin enviar 
una respuesta. 

En la siguiente parte de la prueba se comparan tp->tty_eotct y tp->tty_min. En el modo canónico, 
ambas variables se refieren a líneas de entrada completas, y en modo no canónico se refieren a caracteres. 
Tp->tty_eotct se incrementa cada vez que se coloca un "salto de línea" o un byte en la cola de entrada, y es 
decrementada por in transfer cada vez que una línea o un byte se retira de la cola. Por tanto, esta variable 
cuenta el número de líneas o bytes que han sido recibidos por la tarea de la terminal pero que todavía no se 
han pasado a un lector. Tp—>tty_min indica el número mínimo de líneas (en modo canónico) o caracteres 
(en modo no canónico) que se deben transferir para completar una petición de lectura; su valor siempre es 
1 en modo canónico y puede tener cualquier valor entre O y MAX INPUT (255 en MINIX) inclusive en 
modo no canónico. La segunda mitad de la prueba de la línea 12314 hace que in transfer regrese 
inmediatamente en modo canónico si todavía no se ha recibido una línea completa. La transferencia no se 
efectúa hasta completarse una línea a fin de poder modificar el contenido de la cola si, por ejemplo, el 
usuario teclea subsecuentemente un carácter ERASE o KILL antes de pulsar la tecla ENTER. En modo no 
canónico ocurre un retomo inmediato si todavía no está disponible el número mínimo de caracteres. 

Unas cuantas líneas después, se utilizan tp->tty_inleft y tp->tty_eotct para controlar el ciclo 
principal de in transfer. En modo canónico la transferencia continúa hasta que ya no quedan líneas 
completas en la cola. En modo no canónico tp->tty_eotct es la cuenta de caracteres pendientes. Tp— 
>tty_min controla el ingreso al ciclo, pero no interviene en la determinación de cuándo debe detenerse. 
Una vez que se entra en el ciclo, se transfieren ya sea todos los caracteres disponibles o el número de 
caracteres solicitados en la llamada original, lo que sea menor. 


0|V|D|N|c|C|c|c|7|6|5|4|3|2|l|0| 


V: IN ESC, escapado por LNEXT (CTRL-V) 

D: IN EOF, fin de archivo (CTRL-D) 

N: IN EOT, salto de línea (NL y otros) 

cccc: cuenta de caracteres de los que se hizo eco 

7: Bit 7, puede ponerse en cero si ISTRIP está encendido 

6-0: Bits 0-6, código ASCII 

Figura 3-44. Los campos de un código de carácter tal como se coloca en la cola de entrada. 


Los caracteres son cantidades de 16 bits en la cola de entrada. El código de carácter real que se transfiere 
al proceso de usuario está en los 8 bits bajos. En la Fig. 3-44 se muestra cómo se usan los bits altos. Tres 
sirven como banderas para indicar si el carácter ha escapado (mediante CTRL-V), si marca el fin del 
archivo o si representa uno de varios códigos que indican que ya está completa 
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una línea. Cuatro bits se usan para contar cuánto espacio de pantalla se usa cuando se hace eco del 
carácter. La prueba de la línea 12322 verifica si está encendido el bit INJEOF (D en la figura). Esta prueba 
se hace al principio del ciclo interior porque un fin de archivo (CTRL-D) no se transfiere al lector ni se 
cuenta en el conteo de caracteres. Al transferirse cada carácter, se aplica una máscara para poner en cero 
los ocho bits superiores, y sólo se transfiere al buffer local el valor ASCII contenido en los ocho bits 
inferiores (línea 12324). 


Hay más de una forma de indicar el fin de las entradas, pero se espera que la rutina de entrada 
específica para el dispositivo determine si un carácter recibido es un salto de línea, CTRL-D u otro 
carácter de este tipo, y marcar todos esos caracteres. Intransfer sólo necesita probar si está presente esta 
marca, el bit INEOT (N en la Fig. 3-44), en la línea 12340. Si se detecta la marca, se decrementa tp— 
>tty_eotct. En el modo no canónico todos los caracteres se cuentan de esta forma en el momento de 
colocarse en la cola de entrada, y también se marcan todos los caracteres con el bit IN EOT en ese 
momento, de modo que tp->tty_eotct cuenta los caracteres que todavía no se retiran de la cola. La única 
diferencia en el funcionamiento del ciclo principal de in transfer en los dos modos, canónico y no 
canónico, está en la línea 12343. Aquí se pone en cero tp->tty_inleft cuando se encuentra un carácter 
marcado como salto de línea, pero sólo si está vigente el modo canónico. Por tanto, cuando el control 
regresa al principio del ciclo, éste ter mi na correctamente después de un salto de línea en modo canónico, 
pero en el modo no canónico se hace caso omiso de los saltos de línea. 


Cuando el ciclo termina por lo regular se tiene un buffer local parcialmente lleno que es necesario 
transferir (líneas 12347 a 12353). Luego se envía un mensaje de respuesta si tp->tty_inleft llegó a cero. 
Esto siempre sucede en el modo canónico, pero si está vigente el modo no canónico y el número de 
caracteres transferidos es menor que el número solicitado, no se envía la respuesta. Esto puede parecer 
extraño si tenemos una memoria para los detalles suficientemente buena como para recordar que, siempre 
que hemos encontrado llamadas a in transfer (en do read y handle events), el código que sigue a la 
llamada a in transfer envía un mensaje de respuesta si in transfer regresa después de haber transferido 
más que la cantidad especificada en tp->tty_min, lo que ciertamente será el caso aquí. La razón por la que 
no se envía incondicionalmente una respuesta desde in transfer será evidente cuando expliquemos la 
siguiente fúnción, que invoca in transfer en circunstancias distintas. 


Esa siguiente fúnción es in_process (línea 12367), que se invoca desde el software específico para 
el dispositivo a fin de manejar las tareas de procesamiento comunes que deben efectuarse con todas las 
entradas. Sus parámetros son un apuntador a la estructura tty del dispositivo de origen, un apuntador al 
arreglo de caracteres de ocho bits que se van a procesar, y una cuenta. La cuenta se devuelve al invocador. 
In_process es una fúnción larga, pero sus acciones no son complicadas. Lo que hace es agregar caracteres 
de 16 bits a la cola de entrada que posteriormente será procesada por in transfer. 


In transfer efectúa varias categorías de tratamiento: 

1. Los caracteres normales se agregan a la cola de entrada, extendidos a 16 bits. 

2. Los caracteres que afectan el procesamiento posterior modifican banderas para indicar el efecto, 
pero no se colocan en la cola. 
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3. Los caracteres que controlan el eco causan una acción inmediata y no son colocados en la cola. 

4. A los caracteres con significado especial se les agregan códigos como el bit EOT a su byte alto 
en el momento de colocarse en la cola de entrada. 


Veamos primero una situación totalmente normal: un carácter ordinario, como "x" (código ASCII 
0x78), tecleado a la mitad de una línea corta, sin secuencia de escape vigente, en una terminal configurada 
con las propiedades predeterminadas estándar de MINIX. Tal como se recibe del dispositivo de entrada, 
este carácter ocupa los bits del O al 7 de la Fig. 3-44. En la línea 12385 su bit más significativo, el bit 7, se 
pondría en cero si el bit ISTRIP estuviera encendido, pero la acción predeterminada en MINIX es no 
borrar ese bit, lo que permite introducir códigos completos de 8 bits. De todos modos, esto no afectaría a 
nuestro "x". La acción predeterminada de MINIX es permitir el procesamiento extendido de las entradas, 
así que la prueba del bit IEXTEN de tp->tty_termios.c_lflag (línea 12388) pasa, pero las siguientes 
pruebas fallan en las condiciones que hemos postulado: no hay escape de caracteres vigente (línea 12391), 
esta entrada no es ella misma el carácter de escape de caracteres (línea 12397), y esta entrada no es el 
carácter REPRINT (línea 12405). 

Las pruebas de las siguientes líneas determinan que el carácter de entrada no es el carácter 
especial POSIX VDISABLE, y que tampoco es un CR ni un NL. Por fin, un resultado positivo: está 
vigente el modo canónico, que es lo predeterminado (línea 12424). Sin embargo, nuestro "x" no es el 
carácter ERASE, y tampoco es KILL, EOF (CTRL-D), NL ni EOL, así que a la altura de la línea 12457 
todavía no le habrá pasado nada. En esta línea se determina que el bit 1XON está encendido, por omisión, 
lo que habilita el empleo de los caracteres STOP (CTRL-S) y START (CTRL-Q), pero en las pruebas 
subsecuentes para detectar estos caracteres el resultado es negativo. En la línea 12478 se observa que el bit 
ISIG, que habilita el empleo de los caracteres INTR y QUIT, está encendido por omisión, pero otra vez 
nuestro carácter no coincide con ninguno de ellos. 

De hecho, la primera cosa interesante que podría ocumrle a un carácter ordinario sucede en la 
línea 12491, donde se realiza una prueba para determinar si la cola de entrada y a está llena. Si tal fuera el 
caso, el carácter se desecharía en este punto, pues está vigente el modo canónico, y el usuario no vería su 
eco en la pantalla. (El enunciado continué desecha el carácter, ya que hace que reinicie el ciclo exterior.) 
Sin embargo, dado que hemos postulado condiciones absolutamente normales para esta ilustración, vamos 
a suponer que el buffer todavía no está lleno. La siguiente tueba, para ver si se requiere procesamiento 
especial en modo no canónico (línea 12497), falla, tusando un salto hacia adelante hasta la línea 12512. 
Aquí se invoca echo para exhibir el carácter lia pantalla, pues el bit ECHO de tp->tty_termios.c_lflag está 
encendido por omisión. 

Por último, en las líneas 12515 a 12519, se dispone del carácter colocándolo en la cola de rada. En 
este momento se incrementa tp—>tty_incount, pero como se trata de un carácter ordinario que no está 
marcado con el bit EOT, no se modifica tp->tty_eotct. 

La última línea del ciclo invoca a intransfer si el carácter que se acaba de transferir a la cola la 
llena. Sin embargo, en las condiciones ordinarias que hemos postulado para este ejemplo, in transfer no 
haría nada, incluso si se invocara, porque (suponiendo que se dio servicio normal- 
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mente a la cola y que las entradas anteriores fueron aceptadas cuando se completó la línea de entrada 
previa) tp—>tty_eotct es cero, tp—>tty_min es uno y la prueba al principio de inTransf. (línea 12314) 
causa un retomo inmediato. 


Habiendo pasado por in_process con un carácter ordinario en condiciones ordinarias, regresemos 
al principio de esta función y veamos qué sucede en circunstancias menos ordinarias. Primero 
examinaremos el escape de caracteres, que permite pasar directamente al proceso de usuario un carácter 
que normalmente tendría un efecto especial. Si está vigente un escape de caracteres, está encendida la 
bandera tp—>tty_escaped', cuando se detecta esto en la línea 12391, la bandera se apaga inmediatamente 
y se agrega el bit INESC (bit V en la Fig. 3-44) al carácter actual. Esto da pie a un procesamiento 
especial cuando se hace eco del carácter: los caracteres de control escapados se exhiben como """ más el 
carácter visible correspondiente. El bit IN ESC también evita que el carácter sea reconocido por las 
pruebas que detectan caracteres especiales. Las siguientes líneas procesan el carácter de escape mismo, el 
carácter LNEXT (CTRL-V por omisión). Cuando se detecta el código LNEXT, se enciende la bandera tp- 
>tty_escaped y se invoca rawecho dos veces para exhibir un """ seguido de un retroceso. Esto recuerda al 
usuario del teclado que está vigente n escape, y cuando se hace eco del siguiente carácter éste sobreescribe 
el carácter LNEXT es un ejemplo de carácter que afecta caracteres posteriores (en este caso, sólo el 
carácter que sigue inmediatamente); no se coloca en la cola, y el ciclo se reinicia después de las dos 
llamadas a rawecho. El orden de estas dos pruebas es importante, pues permite teclear el carácter LNEXT 
dos veces seguidas, a fin de pasar la segunda copia a un proceso. 


El siguiente carácter especial que in_process procesa es el carácter REPRINT (CTRL-R). Cuando 
se encuentra este carácter, se invoca reprint (línea 12406), y se vuelven a exhibir las salidas de las que se 
ha hecho eco actualmente. Después se desecha el REPRINT mismo sin afectar la cola de entrada. 


Sería tedioso describir con detalle el manejo de todos y cada uno de los caracteres especiales y el 
código fuente de in_process es sencillo. Sólo mencionaremos unos cuantos puntos más. Un es que el 
empleo de bits especiales en el byte alto del valor de 16 bits que se coloca en la cola de entrada facilita la 
identificación de una clase de caracteres que tienen efectos similares. Así, los caracteres que marcan el fin 
de una línea, EOT (CTRL-D), LF y el carácter alternativo EOL (que) por omisión no está definido), se 
marcan con el bit EOT (bit D en la Fig. 3-44) (líneas 12447 a 12453) para facilitar su reconocimiento 
posterior. Por último, justificaremos el comportamiento peculiar de intransfer que señalamos antes. No se 
genera una respuesta cada vez que esta función termina, aunque en las llamadas a in transfer que hemos 
visto anteriormente parecía que siempre se generaría una respuesta al regresar. Recuerde que la llamada a 
in transfer efectuada por in_process cuando la cola de entrada está llena (línea 12522) no tiene efecto 
cuando este vigente el modo canónico. Sin embargo, si se desea procesamiento no canónico, cada carácter 
marca con el bit EOT en la línea 12499, lo que hace que tp->tty_eotct lo cuente en la línea 12519. A su 
vez, esto hace que se ingrese en el ciclo principal de in transfer cuando se invoca porque la cola de 
entrada está llena en modo no canónico. En tales ocasiones no debe enviarse ningún mensaje al terminar 
in transfer, porque es más probable que se lean más caracteres después de regresar a in_process. De 
hecho, aunque en modo canónico las entradas de un solo READ están limitadas por el tamaño de la cola 
de entrada (255 caracteres en MINIX), en modo no canónico una 
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llamada READ debe poder entregar el número de caracteres requerido por mSK,_POSIX_SSIZE_MAX, 
cuyo valor en MINIX es 32767. 

Las siguientes funciones de tty.c apoyan la entrada de caracteres. Echo (línea 12531) trata unos 
cuantos caracteres de forma especial, pero en general simplemente los exhibe en el lado de salida del 
mismo dispositivo que se está usando para las entradas. Es posible que salidas de un proceso estén siendo 
enviadas a un dispositivo al mismo tiempo que se está haciendo eco de las entradas, y el resultado podría 
ser confuso si el usuario del teclado pulsa la tecla de retroceso. Para resolver este problema, las rutinas de 
salida específicas para el dispositivo siempre asignan TRUE a la bandera tp->tty_reprint cuando se 
producen salidas normales, para que la función invocada para manejar el retroceso sepa que se están 
produciendo salidas mezcladas. Puesto que echo también usa las rutinas de salida específicas para el 
dispositivo, el valor actual de tp->tty_reprint se conserva mi entras se hace eco usando la variable local rp 
(líneas 12552 a 12585). Sin embargo, si acaba de iniciarse una nueva línea de entrada, se asigna FALSE a 
rp en lugar de asu mi r el valor antiguo, a fin de asegurar que tp->tty_reprint se pondrá en cero cuando echo 
termine. 

Tal vez haya usted notado que echo devuelve un valor, por ejemplo, en la llamada de la línea 
12512 de in_process: 


ch = echo(tp, ch) 


El valor devuelto por echo contiene el número de espacios que se usarán en la pantalla para 
exhibir el eco, que puede ser hasta ocho si el carácter es TAB. Esta cuenta se coloca en el campo cccc de 
la Fig. 3-44. Los caracteres ordinarios ocupan un espacio en la pantalla, pero si se hace eco de un carácter 
de control (excepto TAB, NL o CR o un DEL (Ox7F), se exhibe como """ más un carácter ASCII 
imprimible y ocupa dos posiciones en la pantalla. Por otro lado, un NL o un CR ocupa cero espacios. 
Desde luego, el eco en sí debe ser efectuado por una rutina específica para el | dispositivo, y cada vez que 
se debe pasar un carácter al dispositivo se realiza una llamada indirecta utilizando tp->tty_echo, como 
ocurre en la línea 12580 para los caracteres ordinarios. 

La siguiente función, rawecho, sirve para pasar por alto el manejo especial que efectúa echo. 
Kawecho verifica si la bandera ECHO está encendida y, si lo está, envía el carácter a la rutina fp- 
>ttyecho específica para el dispositivo sin procesamiento especial alguno. Aquí se usa una variable local, 
rp, para evitar que cuando rawecho invoque la rutina de salida se modifique el valor de tp->tty_reprint. 

Cuando in_process encuentra un retroceso, invoca la siguiente función, backover (línea 12607). 
Ésta manipula la cola de entrada para eliminar el carácter que estaba en su cabeza, si esto es posible; si la 
cola está vacía o si el último carácter es un salto de línea no es posible retroceder. Aquí se prueba la 
bandera tp—>tty_reprint que mencionamos al describir echo y rawecho. Si la bandera es TRUE, se invoca 
reprint (línea 12618) para colocar en la pantalla una copia limpia de la línea de salida. Luego se consulta 
el campo len del último carácter exhibido (el campo cccc en la P pg, 3-44) para averiguar cuántos 
caracteres será necesario borrar en la pantalla, y para cada carácter se envía una secuencia de caracteres 
retroceso-espacio-retroceso a través de rawecho para eliminar de la pantalla el carácter no deseado. 
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Reprint es la siguiente función. Además de ser invocada por backover, reprint puede ser invocada por el 
usuario oprimiendo la tecla REPRINT (CTRL-R). El ciclo de las líneas 12651 a 1265 recorre hacia atrás 
la cola de entrada en busca del último salto de línea. Si dicho salto se encuentra en la última posición que 
se llenó, no hay nada que hacer y reprint regresa. En caso contrario reprint hace eco del CTRL-R, que 
aparece en la pantalla como la secuencia de dos caracteres '"R", y luego avanza a la siguiente línea y 
vuelve a exhibir la cola de entrada desde el último sait de línea hasta el final. 


Hemos llegado ya a out_process (línea 12677). Al igual que in_process, esta función es invocada 
por las rutinas de salida específicas para el dispositivo, pero es más sencilla. Out_proces es invocada por 
las rutinas de salida específicas para dispositivos RS-232 y seudoterminales, pero no por la rutina de la 
consola. Esta función opera sobre un buffer circular de bytes pero no retira los bytes del buffer. El único 
cambio que out_process hace al arreglo consiste en insertar un carácter CR adelante de un carácter NL en 
el buffer si están encendidos los bits OPOST (habilitar procesamiento de salida) y ONLCR (sustituir NL 
por CR-NL) de tp->tty_termios.oflag. Ambos bits están encendidos por omisión en MINIX. La misión de 
out_process es mantener actualizada la variable tp->tty_position de la estructura tty del dispositivo. Las 
tabulaciones y retrocesos complican la vida. 


La siguiente rutina es devioctl (línea 12763), que apoya a doioctl en la ejecución de la funciones 
tcdrain y tcsetattr cuando se le invoca con las opciones TCSADRAIN o TCSAFLUSH En estos casos, 
do ioctl no puede completar la acción inmediatamente si no se han completado las salidas, así que se 
guarda información referente a la petición en las partes de la estructura tty reservadas para las operaciones 
IOCTL diferidas. Cada vez que handle events se ejecuta, examina el campo tp->tty_ioreq después de 
invocar la rutina de salida específica para el dispositivo, e invoca dev ioctl si hay una operación 
pendiente. DevJioctI prueba tp->tty_outleft para ver si ya se completaron las salidas y, de ser así, realiza 
las mismas acciones que do ioctl habría realizado inmediatamente si no hubiera habido retraso. Para dar 
servicio a tcdrain, lo único que hay que hacer es poner en cero el campo tp->tty_ioreq y enviar el mensaje 
de respuesta al ES, pidiéndole que despierte el proceso que efectuó la llamada original. La variante 
TCSAFLUSH de tcsetattr invoca tty icancel para cancelar las entradas. En ambas variantes de tcsetattr, la 
estructura termios cuya dirección se pasó en la llamada original a IOCTL se copia en la estructura tp- 
> tty_termios del dispositivo. A continuación se invoca setattry después, tal como se hizo con tcdrain, se 
envía mi mensaje de respuesta para despertar al invocador original bloqueado. 


Setattr (línea 12789) es el siguiente procedimiento. Como hemos visto, setattr es invocado por 
do ioctl o dev ioctl para modificar los atributos de un dispositivo terminal, y por do close para 
restablecer los atributos a sus valores predeterminados. Setattr siempre se invoca después de copiar una 
nueva estructura termios en la estructura tty de un dispositivo, porque no basta con copiar sólo los 
parámetros. Si el dispositivo que se está controlando ahora está en modo no canónico, la primera acción 
consiste en marcar con el bit IN EOT todos los caracteres que actualmente están en la cola de entrada, 
como se habría hecho al colocar originalmente dichos caracteres en la cola si entonces hubiera estado 
vigente el modo no canónico. Es más fácil hacer esto (en las líneas 12803 a 12809) que probar si los 
caracteres ya tienen encendido ese bit. No hay forma de saber cuáles atributos acaban de ser modificados 
y cuáles conservan sus valores antiguos. 
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La siguiente acción es verificar los valores de MIN y TIME. En modo canónico, tp->tty_min 
siempre es 1, pues se enciende en la línea 12818. En modo no canónico la combinación de los dos valores 
permite cuatro modos de operación distintos, como vimos en la Fig. 3-35. En las líneas 12823 a 12825, 
primero se asigna a tp->tty_min el valor que se pasó en tp->tty_termios.cc[VMIN], el cual entonces se 
modifica si es cero y tp->tty_termios.cc[VTIME] no es cero. 

Por último, setattr se asegura de que las salidas no serán detenidas si está inhabilitado el control 
XON/XOFF, envía una señal SIGHUP si la velocidad de las salidas se pone en cero, y hace una llamada 
indirecta a la rutina específica para el dispositivo a la que apunta tp->tty_ioctl a fin de efectuar lo que sólo 
puede hacerse en el nivel de dispositivo. 

La siguiente función, tty reply (línea 12845) se ha mencionado varias veces en esta explicación. 
Su acción es sencilla: construir un mensaje y enviarlo. Si por alguna razón falla la respuesta, sobreviene 
un acceso de pánico. Las siguientes funciones son igualmente simples. Sigchar (línea 12866) le pide al 
administrador de memoria que envíe una señal. Si la bandera NOFLSH no está encendida, las entradas 
puestas en cola se eli mi nan: la cuenta de caracteres o líneas recibidas se pone en cero y los apuntadores a 
la cola y la cabeza de la cola se igualan. Ésta es la acción predeterminada. Si se debe atrapar una señal 
SIGHUP, se puede encender NOFLSH para permitir que las entradas y salidas se reanuden después de 
atraparse la señal. Tty icancel (línea 12891) desecha incondicionalmente las salidas pendientes de la 
manera que describimos para sigchar, y además invoca la función específica para el dispositivo a la que 
apunta tp->tty_icancel, a fin de cancelar las entradas que puedan existir en el dispositivo mismo o estar en 
un buffer del código de bajo nivel. 

Tty init (línea 12905) se invoca una vez para cada dispositivo cuando se inicia por primera vez 
tty task, y establece los valores predeterminados. Inicialmente se coloca en las variables tp->tty_icancel, 
tp->tty_ocancel, tp->tty_ioctl y tp->tty_close un apuntador a tty devnop, una función ficticia que no hace 
nada. A continuación, tty init invoca funciones de inicialización específicas para el dispositivo para la 
categoría apropiada de terminal (consola, línea serial o seudoterminal). Éstas establecen los apuntadores 
reales para las funciones específicas para el dispositivo que se invocan indirectamente. Recuerde que si no 
hay dispositivos configurados en una categoría en particular, se crea una macro que regresa 
inmediatamente, para que no se tenga que compilar ninguna parte del código para un dispositivo no 
configurado. La llamada a scr init inicializa el controlador de la consola y también invoca la rutina de 
inicialización para el teclado. 

Tty_wakeup (línea 12929), aunque corta, es extremadamente importante para el funcionamiento 
de la tarea de terminal. Cada vez que se ejecuta el manejador de interrupciones del reloj, es decir, en cada 
tic del reloj, se revisa la variable global ttytimeout (definida en glo.h en la línea 5032) para ver si 
contiene un valor menor que el tiempo actual. Si es así, se invoca ttywakeup. Las rutinas de servicio de 
interrupciones para los controladores de ter mi nal ponen en cero \tty_fimeout, lo que obliga a la ejecución 
de wakeup en el siguiente tic del reloj después de cualquier interrupción de dispositivo terminal. 
Tty timeout también es alterada por settimer cuando un dispositivo ter mi nal está atendiendo una llamada 
READ en modo no canónico y necesita establecer un tiempo de espera, como veremos en breve. Cuando 
tty wakeup se ejecuta, primero inhabilita la siguiente acción de despertar asignando TIME NEVER, un 
valor muy lejano en el futuro, a tty timeout. Luego, tty wakeup examina la lista enlazada de valores de 
temporizador, que está 
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ordenada con los primeros despertares programados más próximos, hasta llegar a uno que posterior al 
tiempo actual. Éste es el siguiente despertar, y se coloca en ttytimeout. Tty wake también pone en cero 
tp->tty_min para ese dispositivo, lo que asegura que la siguiente lectura tendrá éxito incluso si no se han 
recibido bytes, enciende la bandera tp->tty_events para el dispositivo a fin de asegurar que reciba atención 
la siguiente vez que se ejecute la tarea de ter mi nal y retira el dispositivo de la lista de temporizadores. Por 
último, ttywakeup invoca interrupt para enviar el mensaje de despertar a la tarea. Como se mencionó en 
la explicación de la tarea de reloj tty wakeup forma lógicamente parte del código de servicio de 
interrupciones del reloj, ya que sólo se invoca desde ahí. 

La siguiente función, settimer (línea 12958), establece temporizadores para determinar cuándo 
debe regresarse de una llamada READ en modo no canónico; se ejecuta con parámetros de tp un 
apuntador a una estructura tty, y ora, un entero que representa TRUE o FALSE. Primero se revisa la lista 
enlazada de estructuras tty a la que timelist apunta, buscando una entrada existente que coincida con el 
parámetro tp. Si se encuentra una, se retira de la lista (líneas 12968 a 12973). Si se invoca settimer para 
eliminar un temporizados esto es todo lo que debe hacer; si se invoca para establecer un temporizados se 
asigna al elemento tp->tty_time de la estructura tty del dispositivo el tiempo actual más el incremento en 
décimas de segundo especificado por el valor TIME que está en la estructura termios del dispositivo. 
Luego se coloca la entrada en la lista, que se mantiene en orden creciente. Por último, el tiempo de espera 
recién incluido en la lista se compara con el valor de la variable global tty timeout, y ésta se reemplaza si 
el nuevo tiempo de espera se va a vencer antes. 

La última definición de tty.c es ttydevnop (línea 12992), una función de "no hay operación” que 
se direcciona indirectamente en los casos en que un dispositivo no necesita un servicio. Hemos visto que 
tty devnop se usa en tty init como valor predeterminado que se coloca varios apuntadores de fúnción 
antes de invocar la rutina de inicialización para un dispositivo. 


3.9.5 Implementación del controlador de teclado 


Ahora pasamos al código dependiente del dispositivo que apoya la consola de MINIX, que consiste en un 
teclado IBM PC y una pantalla con mapa en la memoria. Los dispositivos físicos que apoyan a éstos son 
totalmente independientes: en un sistema de escritorio estándar la pantalla emplea una tarjeta adaptadora 
(de las cuales hay por lo menos media docena de tipos básico) insertada en el plano posterior, mientras 
que el teclado se apoya en circuitos incorporados en la tarjeta matriz que tienen una interfaz con una 
computadora de un solo chip de 8 bits dentro de la unidad del teclado. Los dos subdispositivos requieren 
apoyo de software totalmente independiente, que se encuentra en los archivos keyboard.c y console.c. 

El sistema operativo ve el teclado y la consola como partes del mismo dispositivo, /dev/ consolé. 
Si hay suficiente memoria disponible en el adaptador de la pantalla, puede compilarse el apoyo de consola 
virtual, y además de /dev/console podría haber dispositivos lógicos adicionales, /dev/ttycl, /dev/ttyc2, etc. 
Sólo las salidas de uno se envían a la pantalla en un momento dado y sólo hay un teclado para las entradas 
a la consola activa. Lógicamente, el teclado está supeditado a la consola, pero esto sólo se manifiesta en 
dos aspectos relativamente menores. Primero, tty table contiene una estructura tty para la consola, y en 
los puntos en los que se proporcional 
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campos distintos para entrada y salida, por ejemplo, los campos tty devread y tty devwrite, se establecen 
apuntadores a funciones en keyboard.c y consolé, c en el momento del inicio. Sin embargo, sólo hay un 
campo tty_priv, y éste apunta sólo a las estructuras de datos de la consola. Segundo, antes de ingresar en 
su ciclo principal, tty task invoca cada dispositivo lógico una vez para inicializarlo. La rutina invocada 
psssi/dev/console está en console.c, y el código de inicialización para el teclado se invoca desde ahí. No 
obstante, la jerarquía implícita bien podría haberse invertido. Siempre hemos examinado las entradas antes 
que las salidas al tratar con dispositivos de E/S y seguiremos con ese patrón, analizando keyboard.c en 
esta sección y dejando la explicación de console.c para la siguiente sección. 


Keyboard.c comienza, al igual que la mayor parte de los archivos fuente que hemos visto, con 
varias instrucciones #include. Una de éstas, sin embargo, es inusual. El archivo keymaps/us-std.src 
(incluido en la línea 13104) no es una cabecera ordinaria; es un archivo fuente en C que da pie a la 
compilación del mapa de teclas por omisión dentro de keyboard.o como un arreglo inicializado. El archivo 
fuente del mapa de teclas no se incluye en los listados al final del libro por causa de su tamaño, pero 
algunas entradas representativas se ilustraron en la Fig. 3-41. Después de las instrucciones #include vienen 
macros que definen diversas constantes. Las del primer grupo se usan en la interacción de bajo nivel con 
el controlador en hardware del teclado. Muchas de éstas son direcciones de puertos de E/S o 
combinaciones de bits que tienen significado en estas interacciones. El siguiente grupo incluye nombres 
simbólicos para teclas especiales. La macro kb. addr (línea 13041) siempre devuelve un apuntador al 
primer elemento del arreglo kb lines, puesto que el hardware de IBM sólo reconoce un teclado. En la 
siguiente línea se define simbólicamente el tamaño del buffer de entrada del teclado como 
KBINBYTES, con un valor de 32. Las siguientes 11 variables sirven para contener diversos estados que 
se deben recordar a fin de interpretar correctamente una digitación. Estas variables se usan de diferentes 
maneras. Por ejemplo, el valor de la bandera capsiock (línea 13046) se conmuta entre TRUE y FALSE 
cada vez que se pulsa la tecla Bloq Mayús (Caps Lock). La bandera shift (línea 13054) se pone en TR UE 
cuando se oprime la tecla SHIFT y en FALSE cuando se suelta dicha tecla. La variable ese se pone en 1 
cuando se recibe un escape de código de detección, y siempre se pone en O después de recibirse el 
siguiente carácter. 


La estructura kb_s de las líneas 13060 a 13065 sirve para seguir la pista a los códigos de detección 
conforme se introducen. Dentro de esta estructura, los códigos se mantienen en un buffer circular, en el 

arreglo ibuf, cuyo tamaño es KB IN BYTES. Se declara kb_lines[NR_CONS], un arreglo de esas 

estructuras, una por cada consola, pero en realidad sólo se usa la primera, ya que siempre se utiliza la 
macro kbaddr para determinar la dirección de la kb_s vigente. Sin embargo, por lo regular nos referimos a 
las variables contenidas en kb_lines[0] empleando un apuntador a la estructura, por ejemplo, kb->ihead, 
para mantener la consistencia con la forma como tratamos otros dispositivos y para hacer que las 
referencias del texto sean congruentes con las contenidas en el listado del código fuente. Desde luego, se 
desperdicia una pequeña cantidad de memoria a causa de los elementos de arreglo no utilizados. Sin 
embargo, si alguien fabrica una PC con apoyo & hardware para múltiples teclados, MINIX está listo; 
basta con modificar la macro kbaddr. 


Map keyO (línea 13084) se define como una macro; devuelve el código ASCII que corresponde a 
un código de detección, sin tener en cuenta los modificadores. Esto equivale a la primera 
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columna (sin SHIFT) del arreglo del mapa de teclas. Su hermano mayor es mapkey (líne 13091), que 
realiza la transformación completa de un código de detección en un código ASCII incluida la 
consideración de las (múltiples) teclas modificadoras que estén oprimidas al mismo tiempo que las teclas 
ordinarias. 

La rutina de servicio de interrupciones del teclado es kbd hw int (línea 13123), invocado cada 
vez que se oprime o suelta una tecla. Esta rutina invoca scan keyboard para obtener el código de 
detección del chip controlador del teclado. El bit más significativo del código de detección se pone en 1 
cuando la interrupción se debe a que se soltó una tecla, y en este caso se hace caso omiso de la tecla a 
menos que se trate de una de las teclas modificadoras. Si la interrupción si debe a que se oprimió una 
tecla, o a que se soltó una tecla modificadora, el código de detección si bruto se coloca en el buffer 
circular si hay espacio, se iza la bandera tp->tty_events para la consola actual (línea 13154) y luego se 
invoca force timeout para asegurarse de que la tarea del reloj iniciará la tarea de la terminal en el 
siguiente tic del reloj. En la Fig. 3-45 se muestran los código de detección en el buffer para una línea corta 
de entrada que contiene dos caracteres en mayúsculas, cada uno precedido por el código de detección de 
oprimir una tecla SHIFT y seguido de código de liberación de dicha tecla. 


42 

35 

170 

18 

38 

38 

24 

57 

54 

17 

182 

24 

19 

38 

32 

28 

L+ 

h 

L- 

e 

1 

L 

o 

SP 

R+ 

W 

R- 

o 

r 

1 

d 

CR 


Figura 3-45. Códigos de detección en el buffer de entrada, con las digitaciones correspondientes abajo, 
para una línea de texto introducida mediante el teclado. L+, L-, R+ y R- representan, respectivamente, 
oprimir y soltar las teclas SHIFT izquierda y derecha. El código de la liberación de una tecla es 128 más el 
código correspondiente a la pulsación de la misma tecla. 


Cuando ocurre la interrupción de reloj, se ejecuta la tarea de terminal misma, y al encontrar 
encendida la bandera tp->tty_events para el dispositivo de la consola, invoca kbread (línea 13165), la 
rutina específica para el dispositivo, empleando el apuntador contenido en el campo tp->tty_devread de la 
estructura tty de la consola. Kb read toma códigos de detección del buffer circular del teclado y coloca 
códigos ASCII en su buffer local, que tiene el tamaño suficiente para contener las secuencias de escape 
que deben generarse como respuesta a ciertos códigos de detección del subteclado numérico. A 

continuación kb read invoca in_process en el código independiente del dispositivo para colocar los 

caracteres en la cola de entrada. En las líneas 13181 a 13183 se usan lock y unlock para proteger el 
decremento de kb->icount contra la posible llegada simultánea de una interrupción del teclado. La llamada 
a makeJbreak devuelve el código ASCT como un entero. Las teclas especiales, como las del subteclado 
numérico y las de función, tienen valores mayores que OxFF en este punto. Los códigos en el intervalo de 
HOME a INSRT (0x101 a OxIOC, definidos en include/minix/keymap.h) son el resultado de oprimir las 
teclas del subteclado numérico, y se convierten en los caracteres de escape de tres caracteres que se 
muestran en la Fig. 3-46 usando el arreglo numpad map. A continuación, las secuencias se pasan a 
in_process (líneas 13196 a 13201). Los códigos más altos no se pasan a in_process, sino que se intenta 
detectarlos 




SEC. 3.9 


TERMINALES 


285 


códigos ALT-FLECHA-IZQUIERDA, ALT-FLECHA-DERECHA o ALT-F1 a ALT-F12, y si se 
encuentra uno de éstos se invoca select console para intercambiar consolas virtuales. 


Tecla 

Código de Detección 

“ASCII” 

Secuencia de Escape 

Inicio 

71 

0x101 

ESC [H 

Flecha Arriba 

72 

0x103 

ESC [A 

Adel. Pág 

73 

0x107 

ESC [V 


74 

0x10A 

ESC [ S 

Flecha Izq. 

75 

0x105 

ESC [D 

5 

76 

0x109 

ESC [ G 

Flecha Der. 

77 

0x106 

ESC [ C 

+ 

78 

0x10B 

ESC [T 

Fin 

79 

0x102 

ESC [Y 

Flecha Abajo 

80 

0x104 

ESC [B 

Retr. Pág. 

81 

0x108 

ESC [U 

Ins 

82 

0x10C 

ESC [ @ 


Figura 3-46. Códigos de escape generados por el subteclado numérico. Cuando los códigos de detección 
de las teclas ordinarias se traducen a códigos ASCII, se asigna a las teclas especiales códigos "seudo- 
ASCII" con valores mayores que OxFF. 


MakeJbreak (línea 13222) convierte códigos de detección a ASCII y luego actualiza las variables 
que siguen la pista al estado de las teclas modificadoras. Antes, empero, makebreak intenta detectar la 
combinación mágica CTRL-ALT-DEL que todos los usuarios de PC conocen como la forma de reiniciar 
bajo MS-DOS. Sin embargo, es deseable una clausura ordenada, así que, en lugar de tratar de iniciar las 
rutinas de PC BIOS se envía una señal SIGABRT a init, el proceso padre de todos los demás procesos. Se 
espera que init atrapará esta señal y la interpretará como un comando para iniciar un proceso ordenado de 
terminar operaciones, antes de causar un retomo al monitor de arranque, desde el cual se podrá ordenar un 
reinicio completo del sistema o un reinicio de MINIX. Desde luego, no es razonable esperar que esto 
funcione siempre. La mayor parte de los usuarios entiende los peligros de una clausura abrupta y no 
oprimen CTRL-ALT-DEL si no está ocurriendo algo en verdad terrible y se ha hecho imposible controlar 
normalmente el sistema. En este punto es factible que el sistema esté tan desorganizado que sea imposible 
enviar ordenadamente una señal a otro proceso. Ésta es la razón de incluir una variable static llamada 
CAD count en make break. La mayor parte de las caídas del sistema dejan el sistema de interrupciones 
funcionando, así que todavía es posible recibir entradas del teclado y la tarea del reloj puede mantener 
operando la tarea de terminal. Aquí MINIX aprovecha el comportamiento esperado 
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de los usuarios de computadora, que muchas veces se ponen a golpear las teclas repetidamente cuando 
sienten que algo no está funcionando correctamente. Si el intento de enviar la señal SIGABRT a init falla 
y el usuario oprime CTRL-ALT-DEL otras dos veces, se efectúa una llamada directa a wreboot, causando 
un retomo al monitor sin pasar por la llamada a init. 


La parte principal de makeJbreak no es difícil de seguir. La variable make registra si el código de 
detección fue generado por la pulsación de una tecla o por su liberación, y entonces la llamada a mapkey 
devuelve el código ASCII en ch. A continuación hay un switch con base en ch (líneas 13248 a 13294). 
Consideremos dos casos, una tecla ordinaria y una tecla especial. Para una tecla ordinaria, ninguno de los 
casos coincide, y no deberá suceder nada tampoco en el caso por omisión (línea 13292), ya que se supone 
que los códigos de las teclas ordinarias sólo se aceptan en la fase de pulsación de la pulsación y liberación 
de una tecla. Si por alguna razón un código de tecla ordinaria es aceptado al liberarse una tecla, se 
sustituirá aquí un valor de -1, y el invocado (kb read) hará caso omiso de este valor. Las teclas especiales, 
como CTRL, se identifican en el punto apropiado del switch, en este caso en la línea 13249. La variable 
correspondiente, en este caso control, registra el estado de make y se sustituye -1 por el código de carácter 
que se devolverá (e ignorará). El manejo de las teclas ALT, CALOCK, NLOCK y SLOCK es más 
complicado, pero para todas estas teclas especiales el efecto es similar: una variable registra el estado 
actual (en el caso de las teclas que sólo surten efecto mientras están oprimidas) o bien conmuta el estado 
previo (en el caso de las teclas de cierre ("LOCK")). 


Hay un caso más que considerar, el de la tecla EXTKEY y la variable ese. Ésta no debe 
confundirse con la tecla ESC del teclado, que devuelve el código ASCII OxIB. No hay forma de generar 
el código EXTKEY por sí solo oprimiendo cualquier tecla o combinación de teclas; se trata del prefijo de 
tecla extendida del teclado de PC, el primer byte de un código de detección de dos bytes que indica que se 
presionó una tecla que no formaba parte del teclado de la PC original pero que tiene el mismo código de 
detección. En muchos casos, el software trata las dos teclas de forma idéntica. Por ejemplo, esto casi 
siempre sucede con la tecla "/" normal y la tecla "/" gris del subteclado numérico. En otros casos, nos 
gustaría distinguir entre dichas teclas. Por ejemplo, muchas organizaciones de teclado para idiomas 
distintos del inglés tratan de forma distinta las teclas ALT izquierda y derecha, a fin de apoyar teclas que 
deben generar tres códigos de carácter distintos. Ambas teclas ALT generan el mismo código de detección 
(56), pero el código EXTKEY precede a éste cuando se oprime la tecla ALT derecha. Cuando se devuelve 
el código EXTKEY, se enciende la bandera ese. En este caso, makebreak regresa de dentro del switch, 
pasando así por alto el último paso antes del retomo normal, que asigna cero a ese en todos los demás 
casos (línea 13295). Esto tiene el efecto de hacer a ese efectiva sólo para el siguiente código que se reciba. 
Si el lector está familiarizado con las complejidades del teclado de PC en su uso ordinario, esto le resultará 
conocido y a la vez un poco extraño, porque el PC BIOS no permite leer el código de detección de una 
tecla ALT y devuelve un valor diferente para el código extendido del que MINIX devuelve. 


Set leds (línea 13303) enciende y apaga las luces que indican si se han oprimido las teclas Bloq 
Núm (Num Lock), Bloq Mayús (Caps Lock) o Bloq Despi (Scroll Lock) de un teclado de PC. Se escribe 
un byte de control, LED CODE, en un puerto de salida para indicar al teclado que el siguiente byte que se 
escriba en ese puerto será para el control de las luces, y el estado de las 
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tres luces se codifica en tres bits de ese siguiente byte. Las siguientes dos funciones apoyan esta 
operación. Kbwait (línea 13327) se invoca para determinar que el teclado está listo para recibir una 
secuencia de comandos, y kback (línea 13343) se invoca para verificar que se ha acusado recibo del 
comando. Ambos comandos utilizan espera activa, leyendo continuamente hasta que se detecta el código 
deseado. Ésta no es una técnica recomendable para manejar la mayor parte de las operaciones de E/S, pero 
el encendido y apagado de las luces del teclado no se efectúa con mucha frecuencia, así que no se 
desperdicia mucho tiempo si se hace de manera ineficiente. Advierta también que tanto kb wait como 
kb ack podrían fallar, y podemos determinar si sucedió esto examinando el código de retomo. Sin 
embargo, ajustar las luces del teclado no tiene la suficiente importancia como para justificar la 
verificación del valor devuelto por cualquiera de las dos llamadas, y set leds se limita a proceder 
ciegamente. 


Puesto que el teclado forma parte de la consola, su rutina de inicialización, kb mit (línea 13359) 
se invoca desde scr init en consolé, c, no directamente desde tty init en tty.c. Si están habilitadas las 
consolas virtuales (es decir, NRCONS en include/minix/config.h es mayor que 1), se invoca kbinit una 
vez para cada consola lógica. Después de la primera vez, la única parte de kb init que es indispensable 
para las consolas adicionales es colocar la dirección de kbread en tp->tty_devread (línea 13367), pero no 
hay problema si se repite el resto de la función. El resto de kbJnit inicializa algunas variables, ajusta las 
luces del teclado e inspecciona el teclado para asegurarse de que no se leerá ninguna digitación remanente. 
Una vez que todo está listo, kb init invoca put_irq_handler y luego enable irq, de modo que se ejecute 
kbd hw int cada vez que se oprima o se suelte una tecla. 


Las siguientes tres funciones son más bien sencillas. Kbdloadmap (línea 13392) es casi trivial; es 
invocada por do ioctl en tty.c para copiar un mapa de teclas del espacio de usuario sobreescribiendo el 
mapa de teclas por omisión compilado al incluirse un archivo fuente de mapa de teclas al principio de 
keyboard.c. 


Func key (línea 13405) se invoca desde kb read para ver si se oprimió una tecla especial que¿ se 
deba procesar localmente. En la Fig. 3-47 se resumen estas teclas y sus efectos. El código (invocado se 
encuentra en varios archivos. Los códigos F1 y F2 activan código en dmp.c, que estudiaremos en la 
siguiente sección. El código F3 activa toggle scroll, que está en consolé.c, y que también se explicará en 
la siguiente sección. Los códigos CF7, CF8 y CF9 causan llamadas ttsigchar, en tty.c. Cuando se agrega 
trabajo con redes a MINIX, se añade un case adicional para |<tetectar el código F5, a fin de exhibir datos 
estadísticos de Ethernet. Está disponible un gran Jtúmero de códigos de detección adicionales que podrían 
usarse para disparar otros mensajes de depuración o eventos especiales de la consola. 


Scankeyboard (línea 13432) opera en el nivel de interfaz de hardware, leyendo y escribiendo rtes 
en los puertos de E/S. Se informa al controlador en hardware del teclado que un carácter fue leído por la 
secuencia de las líneas 13440 a 13442, que lee un byte, lo escribe otra vez con el bit más significativo 
puesto en 1, y luego lo reescribe con el mismo bit puesto en 0. Esto evita que se lean los mismos datos en 
una lectura subsecuente. No hay verificación de estado al leer el teclado, pero de cualquier manera no 
deberá haber problemas, ya que scan keyboard sólo se woca como respuesta a una interrupción, con 
excepción de la llamada desde kb init para despejar cualquier basura que pudiera haber. 
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Tecla 

Propósito 

F1 

Exhibir tablas de procesos 

F2 

Exhibir los detalles de uso de memoria de procesos 

F3 

Conmutar entre desplazamiento por hardware y por software 

F5 

Mostrar datos estadísticos de Ethernet (si se compiló apoyo de red) 

CF7 

Enviar SIGQUIT, mismo efecto que ctrl.A 

CF8 

Enviar SIGINT, mismo efecto que DEL 

CF9 

Enviar SIGKILL, mismo efecto que ctrl.-U 


Figura 3-47. Las teclas de función detectadas porfunc_key(). 


La última función de keyboard.c es wreboot (línea 13450). Si se invoca como resultado de un 
pánico del sistema, wreboot ofrece al usuario la oportunidad de usar las teclas de función para exhibir 
información de depuración. El ciclo de las líneas 13478 a 13487 es otro ejemplo de espera activa. El 
teclado se lee repetidamente hasta que se teclea ESC. Ciertamente nadie podrá asegurar que se necesite 
una técnica más eficiente después de una caída, mientras se espera un comando de rearranque. Dentro del 
ciclo, se invoca fúnckey para ofrecer la posibilidad de obtener información que podría ayudar a analizar 
la causa de una caída. No entraremos en detalles del retomo al monitor, pues son muy específicos para el 
hardware y no tienen mucho que ver con el sistema operativo. 


3.9.6 Implementación del controlador de pantalla 


La pantalla de la IBM PC se puede configurar como varias ter mi nales virtuales si hay suficiente 
memoria disponible. En esta sección examinaremos el código dependiente del dispositivo para la consola, 
y también veremos las rutinas de vaciado de depuración que emplean servicios de bajo nivel del teclado y 
la pantalla. Éstas ofrecen apoyo para una interacción limitada con el usuario en la consola, incluso si otras 
partes del sistema MINIX no están funcionando, y pueden proporcionar información útil aun después de 
una caída casi total del sistema. 

El apoyo específico del hardware para las salidas a la consola PC con pantalla mapeada en la 
memoria está en consolé, c. La estructura consolé se define en las líneas 13677 a 13693. En cierto sentido, 
esta estructura es una extensión de la estructura tty definida en tty.c. Durante la inicialización se asigna al 
campo tp->tty_priv de la estructura tty de una consola un apuntador a su propia estructura consolé. El 
primer elemento de la estructura consolé es un apuntador de regreso a la estructura tty correspondiente. 
Los componentes de una estructura consolé son lo que esperaríamos para una pantalla de video: variables 
para registrar la fila y la columna de la posición del 
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cursor, las direcciones de memoria del principio y el límite de la memoria empleada para la pantalla, la 
dirección de memoria a la que apunta el apuntador base del chip controlador, y la dirección actual del 
cursor. Se usan otras variables para manejar las secuencias de escape. Puesto que los caracteres 
inicialmente se reciben como bytes de ocho bits y deben combinarse con bytes de atributo y transferirse 
como palabras de 16 bits a la memoria de video, se construye el bloque por transferir en cramqueue, un 
arreglo con el tamaño suficiente para contener una fila completa de 80 columnas de pares carácter-atributo 
de 16 bits. Cada consola virtual necesita una estructura consolé, y la memoria para ella se asigna en el 
arreglo cons table (línea 13696). Como hicimos con las estructuras tty y kb_s, usualmente nos referiremos 
a los elementos de una estructura consolé usando un apuntador; por ejemplo, cons->c_tty. 


La función cuya dirección se almacena en la entrada tp—>tty_devwrite de cada consola es 
conswrite (línea 13729). Esta función es invocada desde un solo lugar, handleevents en tty.c. La mayor 
parte del resto de las funciones de consolé, c existen para apoyar esta función. Cuando cons write se 
invoca por primera vez después de que un proceso cliente efectúa una llamada WRITE, los datos por 
exhibir están en el buffer del cliente, que puede encontrarse usando los campos tp—>tty_outproc y tp— 
>tty_virde la estructura tty. El campo tp—>tty_outleft indica cuántos caracteres deben transferirse, y el 
campo tp->tty_outcum inicialmente es cero, lo que indica que todavía no se ha transferido ninguno. Ésta 
es la situación usual cuando se ingresa en cons write, porque normalmente, una vez invocada, transfiere 
todos los datos solicitados en la llamada original. Sin embargo, si el usuario quiere hacer más lento el 
proceso para poder revisar los datos en la pantalla, puede introducir un carácter STOP (CTRL-S) en el 
teclado, izando así la bandera tp->tty_inhibited. Cons write regresa de inmediato cuando está izada esta 
bandera, aunque todavía no se haya completado el WRITE. En tal caso, handle events continuará 
invocando cons write, y cuando tp->tty_inhibited finalmente se arríe en el momento en que el usuario 
introduzca un carácter START (CTRL-Q), cons write continuará con la transferencia interrumpida. 


El único argumento de cons write es un apuntador a la estructura tty de la consola en cuestión, así 
que lo primero que debe hacerse es inicializar cons, el apuntador a la estructura consolé de esa consola 
(línea 13741). Luego, dado que handle events invoca cons write cada vez que se ejecuta, la primera 
acción es una prueba para determinar si realmente hay trabajo que hacer. Se regresa rápidamente si no hay 
trabajo (línea 13746). Después de esto, se ingresa en el ciclo principal délas líneas 13751 a 13778. La 
estructura de este ciclo es muy similar a la del ciclo principal de in transfer en tty.c. Se llena un buffer 
local que puede contener 64 caracteres invocando phys copy para obtener los datos del buffer del cliente, 
se actualizan el apuntador al origen y las cuentas, y luego se transfiere cada uno de los caracteres del 
buffer local al arreglo cons->c_ramqueue, junto con un byte de atributo, para ser transferidos 
posteriormente a la pantalla porflush. Hay más de una forma de efectuar esta transferencia, como vimos en 
la Fig. 3-39. Se puede invocar outchar para que haga esto con cada carácter, pero es evidente que 
ninguno de los servicios especiales de out char se necesitará si el carácter es un carácter visible, si no se 
está formando una secuencia de escape, si no se ha excedido el ancho de la pantalla y si cons- 
>c_ramqueue no está llena. Si no se requiere el servicio completo de out char, el carácter se coloca 
directamente en cons->c_ramqueue junto con el byte de atributo (obtenido de cons->c_attr), y se 
incrementan cons->c_rwords (el índice de la cola), cons->c_column (que sigue la pista a la columna en la 
pantalla) y tbuf (el apuntador 
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al buffer). Esta colocación directa de caracteres en cons—>c_ramqueue corresponde a la línea 
interrumpida del lado izquierdo de la Fig. 3-39. Si es necesario, se invoca outchar (líneas 13766 a 
13777). Éste se encarga de la contabilización y además invoca a flush, que realiza la transferencia final a 
la memoria de pantalla, si es necesario. La transferencia del buffer de usuario al buffer local y a la cola se 
repite en tanto tp->tty_outleft indica que aún hay caracteres que transferir y no se ha izado la bandera tp— 
>tty_inhibited. Cuando se detiene la transferencia, sea porque se completó la operación WRITE o porque 
se izó tp->tty_inhibited, se invoca otra vez flush para transferir los últimos caracteres de la cola a la 
memoria de pantalla. Si la operación se completó (lo que se prueba viendo si tp->tty_outleft es cero), se 
envía un mensaje de respuesta invocando tty reply (líneas 13784 y 13785). 


Además de las llamadas a conswrite desde handleevents, los caracteres que se van a exhibir 
también son enviados a la consola por echo y rawecho en la parte independiente del hardware de la tarea 
de terminal. Si la consola es el dispositivo de salida vigente, las llamadas a través del apuntador tp— 
>ttyecho se dirigen a la siguiente función, consecho (línea 13794). Consecho efectúa todo su trabajo 
invocando out char y luego flush. Las entradas del teclado llegan carácter por carácter y la persona que 
está tecleando desea ver el eco sin un retraso perceptible, así que la colocación de los caracteres en la línea 
de salida no sería satisfactoria. 


Ahora llegamos a out char (línea 13809), la cual realiza una prueba para determinar si se esta 
formando una secuencia de escape, invocando parseescape y luego regresando de inmediato si tal es el 
caso (líneas 13814 a 13816). En caso contrario, se ingresa en un switch para verificar los casos especiales: 
nulo, retroceso, el carácter de alarma, etc. El manejo de casi todos éstos es fácil de seguir. El salto de línea 
y la tabulación son los más complicados, ya que implican cambios complejos a la posición del cursor en la 
pantalla y también podrían requerir desplazamiento. La última prueba es para detectar el código ESC. Si 
se encuentra, se iza la bandera cons->c_esc_stah (línea 13871) y las llamadas fúturas a out char se 
desvían a parse escape hasta que la secuencia está completa. Al final, se toma el valor predeterminado 
para los caracteres imprimibles. Si se ha excedido la anchura de la pantalla, es posible que sea necesario 
desplazar la pantalla, y se invoca flush. Antes de colocar un carácter en la cola de entrada, se realiza una 
prueba para determinar a la cola está llena, y se invoca flush si lo está. La colocación de un carácter en la 
cola requiere la misma contabilización que vimos antes en cons write. 


La siguiente función es scroll screen (línea 13896). Esta función maneja tanto el desplazamiento 
de la pantalla hacia ariba, que es la situación normal que debe manejarse cada vez que se llena la línea 
inferior de la pantalla, como el desplazamiento hacia abajo, que ocurre cuando los comandos de 
movimiento del cursor intentan colocarlo más arriba de la línea superior de la pantalla. Para cada dirección 
de desplazamiento hay tres métodos posibles. Éstos son necesarios para apoyar diferentes clases de 
taijetas de video. 


Examinaremos el caso del desplazamiento hacia arriba. Para comenzar, se asigna a chars tamaño 
de la pantalla menos una línea. El desplazamiento por software se logra con una sola llamada a 
vidvidcopy para mover chars caracteres más abajo en la memoria; el tamaño del bloque que se mueve 
es el número de caracteres en una línea. Vid vid copy puede continuar del final al principio; es decir, si 
se le pide mover un bloque de memoria que desborde el extremo superior del bloque asignado a la pantalla 
de video, obtiene la porción de desbordamiento del 
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extremo inferior del bloque de memoria y lo traslada a una dirección más alta que la parte que se mueve 
más abajo, tratando todo el bloque como un arreglo circular. La sencillez de la llamada oculta una 
operación relativamente lenta. Aunque vidvidcopy es una rutina en lenguaje ensamblador definida en 
klib386.s, esta llamada requiere que la CPU mueva 3840 bytes, lo cual es un trabajo considerable incluso 
en lenguaje ensamblador. 


El método de desplazamiento por software nunca es el predeterminado; se supone que el operador 
sólo lo seleccionará si el desplazamiento por hardware no funciona o no se desea por alguna razón. Una 
razón podría ser el deseo de usar el comando screendump para guardar la memoria de pantalla en un 
archivo. Cuando está vigente el desplazamiento por hardware, es común que screendump produzca 
resultados inesperados, porque es poco probable que el principio de la memoria de pantalla coincida con el 
principio de la pantalla visible. 


En la línea 13917 se prueba la variable wrap como primera parte de una prueba compuesta. Wrap 
es TRUE en pantallas más viejas que pueden manejar el desplazamiento por hardware, y si la prueba falla 
ocurre un desplazamiento sencillo por hardware en la línea 13921, donde el apuntador al origen empleado 
por el chip controlador de video, cons—>c_org, se actualiza de modo que apunte al primer carácter que se 
exhibirá en la esquina superior izquierda de la pantalla. Si wrap es FALSE, la prueba compuesta 
continuará con una prueba de si el bloque que se va a subir en la operación de desplazamiento desborda 
los límites del bloque de memoria designado para esta consola. Si es así, se invoca otra vez vid vid copy 
para realizar un traslado con continuidad del bloque al principio de la memoria asignada a la consola, y se 
actualiza el apuntador al origen. Si no hay traslapo, el control pasa al método simple de desplazamiento 
por hardware que siempre usan los controladores en hardware de video más viejos. Éste consiste en ajustar 
cons->c_org y luego colocar el nuevo origen en el registro correcto del chip controlador. La llamada para 
efectuar esto se emite posteriormente, lo mismo que una llamada para poner en blanco la línea inferior de 
la pantalla. 


El código para el desplazamiento hacia abajo es muy similar al del desplazamiento hacia arriba. 
Por último, se llama memvidcopy para poner en blanco la línea inferior (o superior) direccionada por 
new line. Luego se invoca set_6845 para copiar el nuevo origen de cons—>c_org a los registros 
apropiados, y flush se asegura de que todos los cambios se vean en la pantalla. Hemos mencionado & 
flush (línea 13951) varias veces. Esta función transfiere los caracteres que están en la cola a la memoria de 
video usando mem vid copy, actualiza ciertas variables y luego se asegura de que los números de fila y 
columna sean razonables, ajusfándolos si, por ejemplo, una secuencia de escape ha tratado de colocar el 
cursor en una posición de columna negativa. Por último, se calcula dónde debe estar el cursor y se 
compara esta posición con cons —>c_cur . Si estos valores no coinciden, y si la memoria de video que se 
está manejando actualmente pertenece a la consola virtual vigente, se efectúa una llamada a set_6845 para 
estacer el valor correcto en el registro del cursor del controlador. 


En la Pig. 3-48 se muestra cómo se puede representar el manejo de secuencias de escape no 
máquina de estados finitos. Esto se implementa con parse escape (línea 13986) que se roca al principio de 
outchar si cons->c_esc_state es distinto de cero. Un ESC, en sí, es detectado por outchar y hace que 
cons->c_esc_state sea igual a 1. Cuando se recibe el siguiente carácter parse escape se prepara para el 
procesamiento ulterior colocando '\0' en cons—>c_esc_intro 
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, .. recolectar 

do_escape o : parámetros 

numéricos 

Figura 3-48. Máquina de estados finitos para procesar secuencias de escape. 


(un apuntador al principio del arreglo de parámetros), cons->c_esc_parmv[0] en cons->esc_parmp y ceros 
en el arreglo de parámetros mismo. Luego se examina el primer carácter después del ESC; los valores 
válidos son "[" o bien "M". En el primer caso, el"[" se copia en cons->c_intro y el estado se avanza a 2. 
En el segundo caso, se invoca doescape para efectuar la acción, y el estado de escape se restablece a 
cero. Si el primer carácter después del ESC no es uno de los válidos, se hace caso omiso de él y los 
caracteres subsecuentes se exhiben normalmente otra vez. 


Si se detectó una secuencia ESC [, el siguiente carácter introducido es procesado por el código del 
estado de escape 2. En este punto hay tres posibilidades. Si el carácter es numérico, se extrae su valor y se 
suma a 10 veces el valor existente en la posición a la que actualmente apunta cons—>c_esc_parmp, 
inicialmente cons—>c_esc_parmv[0] (que se inicializó en cero). El estado de escape no cambia. Esto hace 
posible introducir una serie de dígitos decimales y acumular un parámetro numérico grande, aunque el 
valor máximo que MINIX reconoce actualmente es 80, empleado por la secuencia que mueve el cursor a 
una posición arbitraria (líneas 14027 a 14029). Si el carácter es un signo de punto y coma, se avanza el 
apuntador a la cadena de parámetros, a fin de que los valores numéricos subsecuentes puedan acumularse 
en el segundo parámetro (líneas 14031 a 14033). Si se cambiara MAXESCPARMS con objeto de 
reservar un arreglo; más grande para los parámetros, no sería necesario alterar este código para guardar 
valores numéricos adicionales después de la introducción de parámetros adicionales. Por último, si el 
carácter no es un dígito numérico ni un signo de punto y coma, se invoca do escape. 


Do escape (línea 14045) es una de las funciones más largas del código fuente del sistema MINIX, 
aunque la cantidad de secuencias de escape que MINIX reconoce es relativamente modesta. 
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Pese a su longitud, el lector no deberá tener problemas para seguir el código. Después de una llamada 
inicial a flush para asegurarse de que la pantalla de video esté totalmente actualizada, hay una decisión if 
sencilla, dependiendo de si el carácter que sigue de inmediato al carácter ESC es el introductor de 
secuencias de control especiales o no. Si no, sólo hay una acción válida, subir el cursor una línea si la 
secuencia fue ESC M. Cabe señalar que la prueba de la "M" se efectuó dentro de un switch que tiene una 
acción por omisión, como verificación de validez y anticipando la adición de otras secuencias que no 
utilicen el formato ESC [. La acción es representativa de muchas secuencias de escape: se examina la 
variable cons->c_row para determinar si es necesario desplazar la pantalla. Si el cursor ya está en la fila O, 
se emite una llamada SCROLLDOWN a scroll screen, si no, se sube el cursor una línea. Esto último se 
logra decrementando cons—>c_row e invocando flush. Si se encuentra un introductor de secuencias de 
control, se ejecuta el código que sigue al else en la línea 14069. Se realiza una prueba para "[", el único 
introductor de secuencias de control que MINIX reconoce actualmente. Si la secuencia es válida, se asigna 
a valué el primer parámetro encontrado en la secuencia de escape, o cero si no se introdujo ningún 
parámetro numérico (línea 14072). Si la secuencia no es válida, lo único que sucede es que el switch 
grande que sigue (líneas 14073 a 14272) se pasa por alto y el estado de escape se restablece a cero antes 
de regresar de do escape. En el caso más interesante de que la secuencia sea válida, se ingresa en el 
switch. No analizaremos todos los casos; sólo mencionaremos varios de ellos que son representativos de 
los tipos de acciones gobernadas por las secuencias de escape. 


Las primeras cinco secuencias son generadas, sin argumentos numéricos, por las cuatro teclas de 
"flecha" y la tecla Inicio (Home) del teclado de la IBM PC. Las primeras dos, ESC [A y ESC [B, son 
similares a ESC M, excepto que pueden aceptar un parámetro numérico y subir y bajar más de una línea, y 
no desplazan la pantalla si el parámetro especifica un movi mi ento que excede los límites de la pantalla. En 
tales casos, flush atrapa las peticiones que piden salirse de los límites y limita el movimiento a la última 
fila o a la primera, según resulte apropiado. Las siguien-tes dos secuencias, ESC [C y ESC [D, que 
mueven el cursor a la derecha y a la izquierda, están igualmente limitadas por flush. Cuando estas 
secuencias son generadas por las teclas de flecha, no hay argumento numérico, y por tanto ocurre el 
movimiento por omisión de una línea o una columna. 


La siguiente secuencia, ESC [H, puede tomar dos parámetros numéricos, por ejemplo, ESC 
[20;60H. Los parámetros especifican una posición absoluta, no una relativa a la posición actual, y se 
convierten de números basados en 1 a números basados en O para su correcta interpretación. La tecla 
Inicio genera la secuencia predeterminada (sin parámetros) que lleva el cursor a la posición (1, 1). 


Las siguientes dos secuencias, ESC [sJ y ESC [sK, despejan una parte ya sea de la pantalla 
completa o de la línea actual, dependiendo del parámetro introducido. En cada caso se calcula una cuenta 
de caracteres. Por ejemplo, en el caso de ESC [IJ, count recibe el número de caracteres desde el principio 
de la pantalla hasta la posición del cursor, y la cuenta y un parámetro de posición, dst, que puede ser el 
principio de la pantalla, cons—>c_org, o la posición actual del cursor, cons->c_cur, se usan como 
parámetros para una llamada a memvidcopy. Este procedimiento se invoca con un parámetro que hace 
que llene la región especificada con el color de segundo plano vigente. 
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Las siguientes cuatro secuencias insertan y eliminan líneas y espacios en la posición del cursor y 
sus acciones no requieren una explicación detallada. El último caso, ESC [nm (tome nota de que la n 
representa un parámetro numérico, pero la "m" es un carácter literal) afecta cons->c_attr, el byte de 
atributo que se intercala entre los códigos de carácter cuando se escriben en la memoria de video. 

La siguiente función, set_6845 (línea 14280) se usa cada vez que es necesario actualizar el chip 
controlador de video. El 6845 tiene registros internos de 16 bits que se programan 8 bit a la vez, y la 
escritura de un solo registro requiere cuatro operaciones de escritura en un puerto de E/S. Se usan 
llamadas lock y unlock para inhabilitar las interrupciones, que pueden causar problemas si se permite que 
alteren la secuencia. En la Fig. 3-49 se muestran algunos de los registros del chip controlador de video 
6845. 


Registros 

Función 

10-11 

Tamaño del cursor 

12-13 

Dirección donde se comenzará a dibujar la pantalla 

14-15 

Posición del cursor. 


Figura 3-49. Algunos de los registros del 6845. 


La función beep (línea 14300) se invoca cuando es preciso enviar a la salida un cara CTRL-G. 
Esta función aprovecha el apoyo integrado que la PC proporciona para emitir sonidos y enviar una onda 
cuadrada al altavoz. El sonido se inicia con más de las manipulaciones mágicas de los puertos de E/S que 
sólo los programadores en lenguaje ensamblador pueden amar, otra vez cuidando hasta cierto punto que 
una parte crítica del proceso quede protegida contra interrupciones. La parte más interesante del código es 
el empleo de la capacidad de la tarea del reloj para fijar una alarma, que puede servir para iniciar una 
función. La siguiente rutina, stopbeep (línea 14329), es aquella cuya dirección se pone en el mensaje que 
se envía a la tarea del reloj. Stop beep detiene el sonido una vez que ha transcurrido el tiempo designado 
y también pone en cero la bandera beeping que sirve para evitar que las llamadas superfluas a la rutina de 
la alarma audible tengan algún efecto. 


Scr init (línea 14343) es invocada NRCONS veces por tty init. En cada ocasión, su argumentó 
es un apuntador a una estructura tty, un elemento de tty table. En las líneas 14354 y 14355 se calcula Une, 
que se usará como índice del arreglo cons table, se prueba su validez y, si es válida, se usa para inicializar 
cons, el apuntador a la entrada de la consola actual en la tabla. En este punto se puede inicializar el campo 
cons->c_tty con el apuntador a la estructura tty principal para el dispositivo y, a su vez, se puede hacer que 
tp->tty_priv apunte a la estructura console t de este dispositivo. A continuación se invoca kb init para 
inicializar el teclado, y luego se establecen los apuntadores a rutinas específicas para los dispositivos, 
haciendo que tp—>tty_devwrite apunte a cons write y que tp->tty_echo apunte a cons echo. En las líneas 
14368 a 14378 se obtiene la dirección de E/S del registro base del controlador en hardware del CRT y se 
determina la direccción y el tamaño de la memoria de video, y se enciende la bandera wrap (empleada 
para determinar cómo desplazar la pantalla) según la clase de controlador en hardware de video que se 
esta 
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usando. En las líneas 14382 a 14384 se inicializa el descriptor de segmento para la memoria de video en la 
tabla de descriptores globales. 

A continuación viene la inicialización de las consolas virtuales. Cada vez que se invoca scrinit, el 
argumento es un valor diferente de tp, y por tanto se usan un Une y un cons diferentes en las líneas 14393 
a 14396 para proporcionar a cada consola virtual su porción correspondiente de la memoria de video 
disponible. Luego se pone en blanco cada una de las pantallas, en preparación para el inicio, y por último 
se selecciona la consola O como primera consola activa. 

El resto de las rutinas de consolé, c son cortas y simples y las repasaremos rápidamente. Ya 
mencionamos a putk (línea 14408). Esta rutina exhibe un carácter a nombre de cualquier código enlazado 
a la imagen del kemel que requiera el servicio, sin pasar por el sistema de archivos. Toggle scroll (línea 
14429) hace lo que indica su nombre, conmuta el valor de la bandera que determina si se emplea 
desplazamiento por hardware o por software; además, exhibe un mensaje en la posición actual del cursor 
para identificar el modo seleccionado. Cons stop (línea 14442) reinicializa la consola en el estado que 
espera el monitor de arranque, antes de una clausura o un rearranque. ConsorgO (línea 14456) sólo se usa 
cuando se obliga a cambiar de modo de desplazamiento con la tecla F3, o durante la preparación para una 
clausura. Select console (línea 14482) selecciona una consola virtual; se invoca con el nuevo índice y a su 
vez invoca set_6845 dos veces para hacer que el controlador de video exhiba la parte correcta de la 
memoria de video. 

Las últimas dos rutinas dependen en alto grado del hardware. ConJ.oadfont (línea 14497) carga un 
tipo de letra en un adaptador de gráficos para apoyar la operación de IOCTL TIOCSFON. Además, invoca 
ga_program (línea 14540) para que realice una serie de escrituras mágicas en un puerto de E/S que hacen 
que la memoria de tipo de letra del adaptador de video, que la CPU normalmente no puede direccionar, 
sea visible. Luego se invoca phys copy para copiar los datos de tipo de letra en esta área de memoria, y se 
invoca otra secuencia mágica para regresar el adaptador de gráficos a su modo de operación normal. 


Vaciados para depuración 


El grupo final de procedimientos que examinaremos en la tarea de la ter mi nal se diseñaron 
originalmente para ser utilizados sólo temporalmente al depurar MINIX. Éstos se pueden eliminar si no se 
necesita su ayuda, pero muchos usuarios los encuentran útiles y los dejan en su lugar, pues son 
especialmente eficaces cuando se desea modificar MINIX. 

Como hemos visto, íünc key se invoca al principio de kb read para detectar los códigos de 
detección empleados para control y depuración. Las rutinas de vaciado que se invocan cuando se detectan 
las teclas F1 y F2 están en dmp.c. La primera, p_dmp (línea 14613) exhibe información básica de todos los 
procesos, incluida cierta información sobre uso de memoria, cuando se oprime la tecla Fl. La segunda, 
mapdmp (línea 14660) proporciona información más detallada sobre el uso de la memoria cuando se 
oprime F2. Procname (línea 14690) apoya p_dmp buscando los nombres de los procesos. 

Puesto que este código está totalmente contenido dentro del código binario del kemel mismo y no 
se ejecuta como proceso de usuario ni como tarea, es frecuente que siga fúncionando clámente incluso 
después de una caída seria del sistema. Desde luego, sólo se puede acce- 
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der a estas rutinas desde la consola. La información provista por las rutinas de vaciado no puede redirigir a 
un archivo ni a ningún otro dispositivo, así que una copia impresa o el empleo a través de una conexión de 
red quedan excluidos. 

Sugerimos que el primer paso al tratar de agregar cualquier mejora a MfNIX sea la extensión de 
las rutinas de vaciado a modo de proporcionar más información sobre el aspecto del sistema que se desea 
mejorar. 


3.10 LA TAREA DE SISTEMA EN MENIX 


Una consecuencia de hacer que el sistema de archivos y el administrador de memoria sean 
procesos servidores extemos al kemel es que ocasionalmente tienen información que el kemel necesita. 
Sin embargo, esta estructura les impide escribirla simplemente en una tabla del kemel. Por ejemplo, la 
llamada al sistema FORK es manejada por el administrador de memoria. Cuando se crea un proceso 
nuevo, el kemel debe enterarse de ello para poder planificarlo. ¿Cómo puede el administrador de memoria 
decírselo al kemel? 

La solución a este problema es tener una tarea del kemel que se comunique con el sistema de 
archivos y el administrador de memoria por medio del mecanismo de mensajes estándar y que también 
tenga acceso a todas las tablas del kemel. Esta tarea, llamada tarea del sistema, está en la capa 2 de la Fig. 
2-26, y funciona igual que las otras tareas que hemos estudiado en este capítulo. La única diferencia es 
que la tarea del sistema no controla ningún dispositivo de E/S; en vez de ello, al igual que las tareas de 
E/S, implementa una interfaz que en este caso no es con el mundo extemo sino con la parte más intema 
del sistema. Esta tarea tiene los mismos privilegios que las tareas de E/S y se compila junto con ellos en la 
imagen del kemel, así que es más lógico estudiarla aquí que en otro capítulo. 

La tarea del sistema acepta 19 tipos de mensajes, los cuales se muestran en la Fig. 3-50. El 
programa principal de la tarea del sistema, sys task (línea 14837), está estructurado igual que las otras 
tareas: recibe un mensaje, invoca el procedimiento de servicio apropiado, y luego envía una respuesta. A 
continuación examinaremos cada uno de estos mensajes y su procedimiento de servicio. 

El administrador de memoria utiliza el mensaje SYS FORKpara decirle al kemel que acaba de 
nacer un nuevo proceso. El kemel necesita saber esto para poder planificarlo. El mensaje contiene los 
números de ranura dentro de la tabla de procesos que corresponden al padre y al hijo. El administrador de 
memoria y el sistema de archivos también tienen tablas de procesos, y en las tres la entrada k se refiere al 
mismo proceso. De este modo, el administrador de memoria puede especificar sólo los números de ranura 
del padre y del hijo y el kemel sabrá a qué procesos se refieren. 

El procedimiento dofork (línea 14877) primero verifica (línea 14886) si el administrador de 
memoria está alimentando basura al kemel. La prueba utiliza una macro, isoksusem, definida en proc.h, 
para determinar si las entradas para el padre y el hijo en la tabla de procesos son válidas. La mayor parte 
de los procedimientos de servicio de system.c efectúan pruebas similares. Esto es pura paranoia, pero un 
poco de verificación de la consistencia interna no hace daño. Luego do fork 
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Tipo de mensaje 

De 

Significado 

SYSFORK 

MM 

Un proceso bifurcó 

SYSNEWMAP 

MM 

MM Instala mapa de memoria para un nuevo proceso 

SYSGETMAP 

MM 

MM quiere el mapa de memoria de un proceso 

SYSEXEC 

MM 

Establece el apuntador a la pila después de llamar a EXEC 

SYSXIT 

MM 

Un proceso salió 

SYSGETSP 

MM 

MM quiere el apuntador a la pila de un proceso 

SYSTIMES 

FS 

FS quiere los tiempos de ejecución de un proceso 

SYSABORT 

Ambos 

Pánico: MINIX no puede continuar 

SYSSENDSIG 

MM 

Envía una señal a un proceso 

SYSSIGRETURN 

MM 

Aseo después de completarse una señal 

SYSKILL 

FS 

Enviar una señal a un proceso después de la llamada KILL 

SYSENDSIG 

MM 

Aseo después de una señal del kemel 

SYSCOPY 

Ambos 

Copia datos entre procesos 

SYSVCOPY 

Ambos 

Copia múltiples bloques de datos entre procesos 

SYSGBOOT 

FS 

Obtiene parámetros de arranque 

SYSMEM 

MM 

MM quiere el siguiente trozo libre de memoria física 

SYSUMAP 

FS 

Convierte direcciones virtuales en físicas 

SYSTRACE 

MM 

Realiza una operación de la llamada PTRACE 


Figura 3-50. Los tipos de mensajes aceptados por la tarea del sistema. 


copia la entrada de tabla del proceso padre en la ranura del hijo. Aquí es necesario ajustar algunas cosas. 
El hijo queda liberado de cualquier señal pendiente para el padre, y no hereda la situación de rastreo del 
padre. Y, desde luego, toda la información de contabilidad del hijo se pone en cero. 

Después de un FORK, el administrador de memoria asigna memoria al hijo. El kemel debe saber 
dónde está situado el hijo en la memoria a fin de poder establecer debidamente los registros de segmento 
al ejecutar el hijo. El mensaje SYSNEWMAP permite al administrador de memoria dar al kemel el mapa 
de memoria de cualquier proceso. Este mensaje también puede usarse después de que una llamada al 
sistema BRK modifica el mapa. 

El mensaje es man&jaAo por do newmap <\ínea 1491V), que primero áebe copiar e\ mievo mapa 
del espacio de direcciones del administrador de memoria. El mapa no está contenido en el mensaje mismo 
porque es demasiado grande. En teoría, el administrador de memoria podría decirle al kemel que el mapa 
está en la dirección m, donde m es una dirección no permitida. No se supone que el administrador de 
memoria haga esto, pero el kemel de todos modos lo verifica. El 
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mapa se copia directamente en el campo p_map de la entrada de tabla de procesos correspondiente al 
proceso que está obteniendo el nuevo mapa. La llamada a allocsegments extrae información del mapa y 
la carga en los campos p_reg que contienen los registros de segmento. Esto no es complicado, pero los 
detalles dependen del procesador y por esta razón se segregan en una función aparte. 


El mensaje SYS NEWMAP se usa mucho en el funcionamiento normal de un sistema MfNIX. Un 
mensaje similar, SYS GETMAP se usa sólo cuando el sistema de archivos arranca inicialmente. Este 
mensaje solicita una transferencia de la información de mapa de proceso en la dirección opuesta, del 
kemel al administrador de memoria. La transferencia es efectuada por dogetmap (línea 14957). El código 
de las dos funciones es similar, y difiere principalmente en el intercambio de los argumentos de origen y 
destino de la llamada a phys copy utilizada por cada función. 


Cuando un proceso realiza una llamada al sistema EXEC, el administrador de memoria establece 
una nueva pila para él que contiene los argumentos y el entorno, y pasa el apuntador de pila resultante al 
kemel usando SYS EXEC, que es manejado por doexec (línea 14990). Después de la verificación usual 
de la validez del proceso, hay una prueba del campo PROC2 del mensaje. Este campo se utiliza aquí como 
bandera para indicar si el proceso está siendo rastreado y nada tiene que ver con la identificación de los 
procesos. Si está vigente el rastreo, se invoca cause sig para enviar una señal SIGTRAP al proceso. Esto 
no tiene las consecuencias usuales de esta señal, que normalmente terminaría el proceso de destino y 
causaría un vaciado de núcleo. En el administrador de memoria todas las señales enviadas a un proceso 
rastreado, con excepción de SIGKILL, son interceptadas y hacen que el proceso al que se envió la señal se 
detenga para que un programa depurador pueda controlar su posterior ejecución a partir de ese momento. 


La llamada EXEC causa una pequeña anomalía. El proceso que invoca la llamada envía un 
mensaje al administrador de memoria y se bloquea. Con otras llamadas al sistema, la respuesta resultante 
lo desbloquea. Con EXEC no hay respuesta, porque la imagen de núcleo recién cargada no está esperando 
una respuesta. Por tanto, do exec desbloquea por cuenta propia el proceso en la línea 15009. La siguiente 
línea prepara la nueva imagen para ejecutarse, usando la función lock ready que protege contra una 
posible condición de competencia. Por último, la cadena de comandos se guarda para que el proceso se 
pueda identificar cuando el usuario oprima la tecla F1 a fin de exhibir la situación de todos los procesos. 

Los procesos pueden salir en MfNIX ya sea ejecutando una llamada al sistema EXIT, que envía 
un mensaje al administrador de memoria, o siendo terminados por una señal. En ambos casos, el 
administrador de memoria le informa al kemel usando el sistema SYS XIT. El trabajo es efectuado por 
doxit (línea 15027), que es más complicada de lo que podríamos esperar. Encargarse de la información 
de contabilidad es sencillo. El temporizador de alarma, si lo hay, se anula almacenando un cero encima de 
él. Es por esta razón que la tarea del reloj siempre verifica cuándo se ha vencido un temporizador para ver 
si todavía hay alguien interesado. La parte rebuscada de do xit es que el proceso podría haber estado en 
cola tratando de enviar o recibir en el momento en que íue terminado. El código de las líneas 15056 a 
15076 prueba esta posibilidad. Si el proceso que sale se encuentra en la cola de mensajes de cualquier otro 
proceso, se le retira con cuidado. 

En contraste con el mensaje anterior, que es un tanto complicado, SYS GETSP es absolutamente 
trivial. El administrador de memoria lo usa para averiguar el valor del apuntador de pila 
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actual de algún proceso. Este valor se necesita para las llamadas al sistema BRK y SBRK, con objeto de 
ver si el segmento de datos y el segmento de pila han chocado. El código está en do getsp (línea 15089). 


Ahora llegamos a uno de los pocos tipos de mensaje utilizados exclusivamente por el sistema de 
archivos, SYS TIMES. Éste se necesita para implementar la llamada al sistema TIMES, que devuelve los 
tiempos de contabilización al invocador. Todo lo que dotimes (línea 15106) hace es colocar los tiempos 
solicitados en el mensaje de respuesta. Se usan llamadas a lock y unlock para proteger contra una posible 
competencia mientras se accede a los contadores de tiempo. 


Puede ocurrir que el administrador de memoria o bien el sistema de archivos descubra un error 
que haga imposible continuar operando. Por ejemplo, si al arrancar inicialmente el sistema de archivos se 
percata de que el superbioque en el dispositivo raíz se ha corrompido irremediablemente, entra en pánico y 
envía un mensaje SYS ABORT al kemel. También es posible que el superusuario fuerce un retomo al 
monitor de arranque y/o un rearranque, empleando el comando reboot, que a su vez emite la llamada al 
sistema REBOOT. En cualquiera de estos casos, la tarea del sistema ejecuta do abort (línea 15131), que 
copia instrucciones al monitor, si es necesario, y luego invoca wreboot para completar el proceso. 


La mayor parte del trabajo de manejo de señales es efectuada por el administrador de memoria, 
que verifica si el proceso al que se va a enviar una señal está habilitado para atrapar o ignorar la señal, si 
quien envía la señal tiene derecho a hacerlo, etc. Sin embargo, el administrador de memoria no puede él 
mismo causar la señal, lo que requiere meter cierta información en la pila del proceso al que se envía la 
señal. 


El manejo de señales antes de POSIX era problemático porque el hecho de atrapar una señal 
restauraba la respuesta predeterminada a las señales. Si se requería continuar con el manejo especial de las 
señales subsecuentes, el programador no podía garantizar la confiabilidad. Las señales son asincronas, y 
bien podía ser que llegara una segunda señal antes de volverse a habilitar el manejo. El manejo de señales 
al estilo POSIX resuelve este problema, pero el precio es un mecanismo más complicado. El sistema 
operativo implementaba el manejo de señales al estilo antiguo metiendo cierta información en la pila del 
proceso destinatario de la señal, de forma similar a como una interrupción agrega información. Entonces, 
el programador escribía un nejador que terminaba con una instrucción de retomo, removiendo la 
información necesaria a continuar con la ejecución. Cuando se recibe una señal, POSIX guarda más 
información de la que puede manejarse sin problemas de esta manera. Después, se debe efectuar trabajo 
adicional, antes de que el proceso que recibió la señal pueda reanudar lo que estaba haciendo. Por tanto, el 
administrador de memoria tiene que enviar dos mensajes a la tarea del sistema para procesar una señal. La 
recompensa por este esfuerzo es un manejo más confiable de las señales. 


Cuando se debe enviar una señal a un proceso, se envía el mensaje SYS SENDSIG a la tarea del 
sistema, y el trabajo es efectuado por dosendsig (línea 15157). La información necesaria para manejar 
señales al estilo POSIX está en una estructura sigcontext, en la que se guarda el contenido del registro del 
procesador, y una estructura sigffame, que contiene información sobre la forma en que el proceso debe 
manejar las señales. Ambas estructuras requieren cierta inicialización, pero el trabajo básico de 
do sendsig consiste sólo en colocar la información requerida en la pila del proceso destinatario de la señal 
y ajustar el contador de programa y al apuntador de pila de 



300 


ENTRAD A/SALIDA 


CAP. 3 


dicho proceso de modo que el código de manejo de señales se ejecute la siguiente vez que el planificador 
permita que el proceso se ejecute. 

Cuando un manejador de señales al estilo POSIX termina su trabajo, no remueve la dirección 
donde se reanuda la ejecución del proceso interrumpido, como sucede con las señales al estilo antiguo. El 
programador que escribe el manejador incluye una instrucción retum (o su equivalente en un lenguaje de 
alto nivel), pero la manipulación de la pila por parte de la llamada SENDSIG hace que la instrucción 
retum cause una llamada al sistema SIGRETURN. El administrador de memoria envía entonces un 
mensaje SYS SIGRETURN a la tarea del sistema. Este mensaje es manejado por dosigretum (línea 
15221), que copia la estructura sigcontext de vuelta en el espacio del kemel y luego restaura los registros 
del proceso destinatario de la señal. La próxima vez que el planificador permita que el proceso 
interrumpido se ejecute, éste reanudará su ejecución en el punto en el que fue interrumpido, conservando 
cualquier manejo especial de señales que se haya establecido previamente. 


La llamada al sistema SIGRETURN, a diferencia de la mayor parte de las otras llamadas que 
describimos en esta sección, no es requisito de POSIX. Se trata de una invención de MINIX, una forma 
cómoda de iniciar el procesamiento necesario cuando finaliza el manejador de señales. No es conveniente 
que los programadores usen esta señal, pues no será reconocida por otros sistemas operativos, y en 
cualquier caso no hay necesidad de hacer referencia explícita a ella. 

Algunas señales provienen del interior de la imagen del kemel, o son manejadas por el kemel 
antes de pasar al administrador de memoria. Éstas incluyen las señales que se originan en las tareas, como 
las alarmas de la tarea del reloj, o las digitaciones que causan señales y que son detectadas por la tarea de 
la terminal, así como las señales causadas por excepciones (como una división entre cero o instrucciones 
no permitidas) detectadas por la CPU. Las señales que se originan en el sistema de archivos también son 
manejadas primero por el kemel. El sistema de archivos usa el mensaje SYS KILL para solicitar la 
generación de una señal de este tipo. El nombre tal vez sea un tanto engañoso, pues esto nada tiene que 
ver con el manejo de la llamada al sistema KILL, empleada por los procesos ordinarios para enviar 
señales. Este mensaje es manejado por do kill (línea 15276), que realiza la verificación usual de la validez 
del origen del mensaje y luego invoca cause sig para pasar realmente la señal al proceso. Las señales que 
se originan en el kemel también se pasan al proceso mediante una llamada a esta función, que inicia las 
señales enviando un mensaje KSIG al administrador de memoria. 


Cuando el administrador de memoria termina con una de estas señales tipo KSIG, envía un 
mensaje SYS ENDSIG de vuelta a la tarea del sistema. Este mensaje es manejado por do endsig (línea 
15294), que decrementa la cuenta de señales pendientes y, si llega a cero, apaga el bit SIG PENDING 
para el proceso destinatario de la señal. Si no hay otras banderas encendidas que indiquen razones por las 
que el proceso no debe ejecutarse, se invocará lock ready para permitir que el proceso se ejecute otra vez. 

El mensaje SYS COPY es el que más se usa, pues se necesita para que el sistema de archivos y el 
administrador de memoria puedan copiar información de y a los procesos de usuario. 

Cuando un usuario ejecuta una llamada READ, el sistema de archivos examina su caché para ver 
si tiene el bloque que se necesita. Si no es así, el FS envía un mensaje a la tarea de disco apropiada para 
cargarlo en el caché, y luego envía otro mensaje a la tarea del sistema para decirle 
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le copie el bloque en el espacio de direcciones del proceso de usuario. En el peor de los casos se necesitan 
siete mensajes para leer un bloque; en el mejor de los casos se necesitan cuatro mensajes. Ambos casos se 
muestran en la Fig. 3-51. Estos mensajes son una fuente importante de gasto extra en MINIX y son el 
precio que se paga por un diseño altamente modular. 




(«) <b) 

Fisura 3-51. (a) En el peor de los casos se requieren siete mensajes para leer un bloque (b) En 
el mejor de los casos sólo se requieren cuatro mensajes. 


Como acotación, en el 8088, que no tenía protección, habría sido fácil hacer trampa y dejar que el 
sistema de archivos copiara los datos en el espacio de direcciones del invocador, pero esto habría violado 
el principio de diseño. Cualquier persona que tenga acceso a una máquina tan antigua y que esté 
interesada en mejorar el rendimiento de MINIX debería examinar detenidamente este mecanismo para ver 
cuánto comportamiento inapropiado se puede tolerar a fin de obtener ganancia en el rendimiento y cuánta 
sería ésta. Desde luego, esta forma de mejoramiento no está disponible en las máquinas de clase Pentium, 
que tienen mecanismos de protección. 


El manejo de una petición SYS COPY es directo; corre por cuenta de do copy (línea 15316) y 
consiste casi exclusivamente en la extracción de los parámetros del mensaje y una invocación de 
piscopy. 


Una forma de reducir la ineficiencia del mecanismo de transferencia de mensajes es empacar 
múltiples peticiones en un solo mensaje. El mensaje SYS VCOPY se encarga de esto. El contenido de 
este mensaje es un apuntador a un vector que especifica múltiples bloques que deberán copiarse entre 
posiciones de memoria. La fúnción do veopy (línea 15364) ejecuta un ciclo, extrayendo las direcciones de 
origen y de destino y las longitudes de los bloques e invocando 
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physcopy repetidamente hasta finalizar todas las operaciones de copiado. Esto es similar a la capacidad 
de los dispositivos de disco para manejar múltiples transferencias con base en una sola petición. 


La tarea del sistema recibe vados tipos de mensajes más, casi todos muy sencillos. Dos de éstos 
normalmente sólo se usan durante el inicio del sistema. El sistema de archivos envía un mensaje 
SYS GBOOTpara solicitar los parámetros de arranque. Ésta es una estructura, bparam s declarada en 
include/minix/boot.h, que permite al programa monitor del arranque especificar diversos aspectos de la 
configuración del sistema antes de iniciarse MfNIX. La función do gboot (línea 15403) lleva a cabo esta 
operación, que no es más que un copiado de una parte de la memoria a otra. También durante el inicio, el 
administrador de memoria envía a la tarea del sistema una serie de mensajes SYS MEM para solicitar la 
base y el tamaño de los trozos de memoria disponibles. Do mem (línea 15424) maneja esta petición. 


El mensaje SYS ÜMAP es utilizado por procesos fuera del kemel para solicitar el cálculo de la 
dirección de memoria física para una dirección virtual dada. Do umap (línea 15445) realiza esto 
invocando umap, que es la función que se invoca desde dentro del kemel para efectuar esta conversión. 


El último tipo de mensaje que examinaremos es SYSTRACE, que apoya la llamada al sistema 
PTRACE, la cual se utiliza para depuración. La depuración no es una fúnción fundamental de sistema 
operativo, pero el apoyo del sistema operativo puede simplificarla considerableme. Con la ayuda del 
sistema operativo, un depurador puede inspeccionar y modificar la memoria utilizada por un proceso 
sometido a prueba, así como el contenido de los registros del procesador, los cuales se almacenan en la 
tabla de procesos mientras el programa que se está depurando no está en ejecución. 


Normalmente, un proceso se ejecuta hasta que se bloquea para esperar E/S o hasta que agota un 
cuanto de tiempo. Casi todos los diseños de CPU ofrecen también un mecanismo que permite limitar a los 
procesos a la ejecución de una sola instrucción, o hacer que los procesos se ejecuten sólo hasta llegar a 
una instrucción dada, estableciendo un punto interruptor. El aprovechamiento de estas posibilidades 
favorece un análisis detallado de los programas. 


Hay once operaciones que pueden llevarse a cabo usando PTRACE. En la ejecución de unas 
cuantas únicamente interviene el administrador de memoria, pero para las demás el administrador de 
memoria envía un mensaje SYS TRACE a la tarea del sistema, la cual entonces invoca do trace (línea 
15467). Esta fúnción implementa un switch basado en el código de la operación de rastreo. Las 
operaciones generalmente son sencillas. MINIX utiliza un bit P STOP en la tabla de procesos para 
reconocer que se está efectuando depuración, y es asignado por el comando para detener el proceso (caso 
TSTOP) o reasignado para reiniciarlo (caso TJRESUME). La depuración depende del apoyo de 
hardware, y en los procesadores Intel está bajo el control de un bit del registro de banderas de la CPU. 
Cuando ese bit está asignado, el procesador sólo ejecuta una instrucción, y luego genera una excepción 
SIGTRAP. Como ya se mencionó, el administrador de memoria detiene el programa que se está 
rastreando cuando se le envía una señal. Este TRACEBITes manipulado por los comandos T STOP y 
TJ5TEP. Hay dos formas de establecer puntos interruptores: usando el comando T SETINS para 
reemplazar una instrucción por un código especial que genera una SIGTRAP, o bien empleando el 
comando T SETUSER para modificar los registros especiales 
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de punto interruptor. En cualquier clase de sistema al cual se pueda trasladar MINIX seguramente será 
posible implementar un depurador valiéndose de técnicas similares, pero el traslado de estas funciones 
requiere estudiar el hardware de que se trata. 


La mayor parte de los comandos ejecutados por dotrace o bien regresan o modifican valores en el 
espacio de texto o de datos, o en la entrada de tabla de procesos, del proceso rastreado, y el código es 
sencillo. Es peligroso permitir la alteración de ciertos registros y ciertos bits de las banderas de la CPU, así 
que el código incluye muchas verificaciones que manejan el comando TSETUSER a fin de evitar tales 
operaciones. 


Al final de system.c hay varios procedimientos de utilería que se emplean en diversos lugares del 
kemel. Cuando una tarea necesita causar una señal (p. ej., la tarea del reloj necesita causar una señal 
SIGALRM, o la tarea de la terminal necesita causar una señal SIGINT), invoca causesig (línea 15586). 
Este procedimiento enciende un bit en el campo p_ pending de la entrada de tabla de procesos 
correspondiente al proceso destinatario de la señal y luego verifica si el administrador de memoria 
actualmente está esperando un mensaje de ANY, es decir, si está ocioso y esperando la siguiente petición 
de procesamiento. Si el administrador de memoria está ocioso, se invoca inform para decirle que se 
encargue de la señal. 


Inform (línea 15627) se invoca sólo después de verificar que el administrador de memoria no está 
ocupado, como acaba de explicarse. Además de la llamada desde cause sig, se le llama desde mmrec 
(enproc.c) cada vez que el administrador de memoria se bloquea y hay señales del kemel pendientes. 
Inform construye un mensaje del tipo KSIG y lo envía al administrador de memoria. La tarea o proceso 
que invoca cause sig continúa su ejecución tan pronto como el mensaje se copia en el buffer de recepción 
del administrador de memoria; no espera hasta que se ejecuta el administrador de memoria, como sería el 
caso si se utilizara el mecanismo de envío normal, que | hace que el remitente se bloquee. Sin embargo, 
antes de regresar, inform invoca lock_pick_proc, que planifica el administrador de memoria para que se 
ejecute. Puesto que las tareas tienen una prioridad mayor que los servidores, el administrador de memoria 
no se ejecutará en tanto no se satisfagan todas las tareas. Cuando la tarea señalizadora termine, se 
ingresará en el planificador. Si el administrador de memoria es el proceso ejecutable con la más alta 
prioridad, se ejecutará y procesará la señal. 


El procedimiento umap (línea 15658) es de utilidad general y establece la correspondencia |ntre 
una dirección virtual y una física. Como hemos señalado, domap, que da servicio al mensaje 
SYS UMAP, invoca este procedimiento. Sus parámetros son un apuntador a la entrada atabla de procesos 
del proceso o tarea con cuyo espacio de direcciones virtuales se establecerá (I correspondencia, una 
bandera que especifica el segmento de texto, de datos o de pila, la erección virtual misma y una cuenta de 
bytes. Esta última es útil porque umap verifica que todo |buffer que comienza en la dirección virtual esté 
dentro del espacio de direcciones del proceso. Para ello, umap debe conocer el tamaño del buffer. La 
cuenta de bytes no se utiliza para el mapeo sí, sólo para esta verificación. Todas las tareas que copian 
datos de o hacia el espacio de usuarios calculan la dirección física del buffer usando umap. En el caso de 
los controladores de dispositivos, resulta práctico poder obtener los servicios de umap a partir del número 
del proceso en lugar de un apuntador a una entrada de la tabla de procesos. Numap (línea 15697) se 
encarga de esto invocando proc addr para convertir su primer argumento e invocando después umap. 
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La última función definida en system.c es allocsegments (línea 15715), la cual es invocado por 
donewmap, así como por la rutina main del kemel durante la inicialización. Esta definición depende en 
gran medida del hardware; recibe las asignaciones de segmentos que están registrada en una entrada de la 
tabla de procesos y manipula los registros y descriptores que el procesador Pentium usa para apoyar los 
segmentos protegidos en el nivel de hardware. 


3.11 RESUMEN 


La entrada/salida es un tema importante que muchas veces se descuida. Una fracción sustancia de 
todo sistema operativo se ocupa de E/S. Comenzamos por examinar el hardware de E/S y 1, relación entre 
los dispositivos de E/S y los controladores en hardware de E/S, que son los que deben manejar el software. 
Luego vimos los cuatro niveles de software de E/S: las rutinas de interrupción, los controladores de 
dispositivos, el software de E/S independiente del dispositivo y las bibliotecas de E/S y los spoolers que se 
ejecutan en el espacio de usuario. 

A continuación estudiamos el problema del bloqueo mutuo y la forma de enfrentarlo. Ocurre un 
bloqueo mutuo cuando se concede a cada uno de un grupo de procesos acceso exclusivo a cierto recursos, 
y cada uno quiere además otro recurso que pertenece a otro proceso del grupo. Todo ellos se bloquean y 
ninguno puede ejecutarse jamás. Se puede evitar el bloqueo mutuo estructurando el sistema de modo que 
nunca pueda ocurrir, por ejemplo, decretando que un proceso sólo puede adueñarse de un recurso a la vez. 
También puede evitarse el bloqueo mutuo examinando todas las peticiones de recursos para determinar si 
dan pie a una situación en la que es posible el bloqueo mutuo (un estado inseguro) y rechazar o diferir las 
peticiones que pudieran causar problemas. 

Los controladores de dispositivos de MINIX se implementan como procesos incorporados en el 
kemel. Examinamos el controlador del disco en RAM, del disco duro, del reloj y de la terminal. La tarea 
de alarma sincrónica y la tarea del sistema no son controladores de dispositivos pero su estructura es muy 
similar. Cada una de estas tareas tiene un ciclo principal que obtiene peticiones y las procesa, devolviendo 
tarde o temprano respuestas para informar qué sucedió. Todas las tareas están ubicadas en el mismo 
espacio de direcciones. Las tareas controladoras del disco en RAM, el disco duro y el disquete utilizan una 
sola copia del mismo ciclo principal y también comparten funciones. No obstante, cada una es un proceso 
independiente. Una sola tarea de terminal apoya varias terminales diferentes, usando la consola del 
sistema, las líneas en serie y las conexiones de red. 

Los controladores de dispositivos tienen relaciones variables con el sistema de interrupciones. Los 
dispositivos que pueden completar su trabajo rápidamente, como el disco en RAM y la pantalla mapeados 
en la memoria, ni siquiera usan interrupciones. La tarea controladora del disco duro realiza la mayor parte 
de su trabajo en el código de la tarea mismo, y los manejadores de interrupciones se limitan a devolver 
información de estado. El manejador de interrupciones del reloj realiza varias operaciones de contabilidad 
por sí mismo y sólo envía un mensaje a la tarea del reloj cuando hay trabajo del que el manejador no se 
puede ocupar. El manejador de interrupciones del teclado guarda en buffers las entradas y nunca envía 
mensajes a su tarea; más bien, modifica una variable inspeccionada por el manejador de interrupciones del 
reloj, el cual envía posteriormente un mensaje a la tarea de la terminal. 
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1. Imagine que los avances en la tecnología de los chips hacen posible colocar todo un controlador en 
hardware, incluida toda la lógica de acceso a buses, en un chip de bajo costo. ¿Cómo afectaría eso el 
modelo de la Fig. 3-1? 

2. Si un controlador en hardware de disco escribe en la memoria los bytes que recibe del disco tan 
rápidamente como los recibe, sin usar buffers internos, ¿tendría alguna utilidad concebible la 
intercalación? Explique. 

3. Con base en la velocidad de rotación y la geometría de los discos, determine las tasas de bits para las 
transferencias entre el disco mismo y el buffer de controlador en hardware para un disco flexible y para un 
disco duro. Compare estas tasas con las de otras formas de E/S (líneas en serie y redes). 

4. Un disco tiene doble intercalación, como en la Fig. 3-4(c), con ocho sectores de 512 bytes en cada pista, 
y una velocidad de rotación de 300 rpm. ¿Cuánto tiempo toma leer todos los sectores de una pista en 
orden, suponiendo que el brazo ya está en la posición correcta y que se necesita media rotación para lograr 
que el sector O esté bajo la cabeza? Calcule la tasa de datos. Repita ahora el problema para un disco sin 
intercalación con las mismas características. ¿Cuánto se degrada la tasa de datos a causa de la 
intercalación? 

5. El multiplexor de terminales DM-11, que se usó en la PDP-11 hace muchos, muchos años, muestreaba 
cada línea de terminal (semidúplex) a siete veces la tasa en bauds para ver si el bit entrante era un 0 o un 
1. El muestreo de la línea tomaba 5.7 microsegundos. ¿Cuántas líneas de 1200 bauds podía manejar el 
DM-II? 

6. Una red de área local se usa como sigue. El usuario emite una llamada al sistema para escribir paquetes 
de datos en la red. A continuación, el sistema operativo copia los datos en un buffer del kemel, y luego los 
copia en la taijeta del controlador en hardware de la red. Una vez que todos los bytes están seguros dentro 
del controlador, se envían por la red a razón de 10 megabits/s. El controlador de red receptor almacena 
cada bit un microsegundo después de que se envía. Cuando llega el último bit, la CPU de destino se 
interrumpe, y el kemel copia el paquete recién llegado en un buffer del kemel para inspeccionarlo. Una 
vez que el kemel ha determinado a qué usuario va dirigido el paquete, copia los datos en el espacio del 
usuario. Si suponemos que cada interrupción y su procesamiento toma 1 microsegundo, que los paquetes 
tienen 1024 bytes (no tome en cuenta las cabeceras) y que se requiere 1 microsegundo para copiar un byte, 
¿con qué velocidad máxima puede un proceso enviar datos a otro? Suponga que el transmisor se bloquea 
hasta que el procesamiento term in a en el lado del receptor y regresa un acuse de recibo. Por sencillez, 
suponga que el üempo que toma recibir el acuse de recibo es tan pequeño que puede ignorarse. 

7. ¿Qué significa "independencia del dispositivo"? 

8. ¿En cuál de las cuatro capas de software de E/S se realiza cada una de las siguientes actividades? 

(a) Calcular la pista, sector y cabeza para una lectura de disco. 

(b) Mantener un caché de los bloques recientemente utilizados. 

(c) Escribir comandos en los registros de los dispositivos. 

(d) Verificar que el usuario tenga permiso de usar el dispositivo. 

(e) Convertir enteros binarios a ASCII para imprimirlos. 

9. ¿Por qué los archivos de salida para la impresora normalmente se colocan en un spool de disco antes de 
imprimirse? 
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10. Considere la Fig. 3-8. Suponga que en el paso (o) C solicitara S en lugar de solicitar R. ¿Daría lugar 
esto a un bloqueo mutuo? ¿Y si solicitara tanto 5" como R? 

11. Examine con detenimiento la Fig. 3-ll(b). Si Susana pide una unidad más ¿lleva esto a un esta do 
seguro o a uno inseguro? ¿Y si la petición proviniera de Miguel en lugar de Susana? 

12. Todas las trayectorias de la Fig. 3-12 son horizontales o verticales. ¿Puede usted imaginar una 
circunstancia en la que también pueda haber trayectorias diagonales? 

13. Suponga que el proceso A de la Fig. 3-13 solicita la última unidad de cinta. ¿Esta acción da pie a un 
bloqueo mutuo? 

14. Una computadora tiene seis unidades de cinta, y n procesos compiten por ellas. Cada proceso puede 
necesitar dos unidades. ¿Con qué valores de n el sistema está libre de bloqueos mutuos? 

15. ¿Puede un sistema estar en un estado que no es un bloqueo mutuo ni un estado seguro? De ser así, cite 
un ejemplo. Si no, demuestre que todos los estados son bloqueos mutuos o bien estados seguros. 

16. Un sistema distribuido que emplea buzones tiene dos primitivas IPC, SEND y RECEIVE. La segunda 
primitiva especifica el proceso del que se desea recibir, y se bloquea si no hay un mensaje disponible de 
ese proceso, aunque haya mensajes esperando de otros procesos. No hay recursos compartidos, pero los 
procesos necesitan comunicarse con frecuencia respecto a otros asuntos. ¿Son posibles los bloqueos 
mutuos? Explique. 

17. En un sistema de transferencia electrónica de fondos hay cientos de procesos idénticos que funcionan 
como sigue. Cada proceso lee una línea de entrada que especifica una cantidad de dinero, la cuenta a la 
que debe abonarse y la cuenta a la que debe cargarse. Luego el proceso pone un candado a ambas cuentas 
y transfiere el dinero, liberando los candados cuando termina. Si hay muchos procesos ejecutándose en 
paralelo, existe el peligro, muy real, de que habiendo puesto un candado a la cuenta x, un proceso no 
pueda poner un candado a y porque otro proceso ya le puso un candado y ahora está esperando para poner 
un candado a x. Invente un esquema que evite los bloqueos mutuos. No libere el registro de una cuenta 
antes de haber completado las transacciones. (Dicho de otro modo, no se permiten soluciones que ponen 
un candado a una cuenta y luego lo liberan de inmediato si la otra tiene un candado.) 

18. Se está usando el algoritmo del banquero en un sistema con w clases de recursos y n procesos. En el 
límite de m y n grandes, el número de operaciones que deben realizarse para verificar la seguridad de un 
estado es proporcional a m a n b . ¿Qué valores tienen a y b? 

19. Cenicienta y el Príncipe se están divorciando. Para dividir sus posesiones, han acordado el siguiente 
algoritmo. Cada mañana, cada cónyuge puede enviar una carta al abogado del otro solicitando uno de sus 
bienes. Puesto que la entrega de una carta tarda un día, han convenido en que, si ambos descubre que han 
solicitado la misma cosa el mismo día, al día siguiente enviarán una carta cancelando la reclamación. 
Entre sus bienes está su perro, Woofer*, la perrera de Woofer, su canario, Tweeter, y la jaula de Tweeter. 
Los animales aman sus hogares, así que se ha acordado que cualquier división de bienes que separe un 
animal de su casa no es válida, y requiere que toda la división se reinicie desde el principio. Tanto 
Cenicienta como el Príncipe desean desesperadamente quedarse con Woofer. A fin de poder irse de 
vacaciones (por separado), cada uno de los cónyuges ha programado una computadora personal que se 
encargue de la negociación. Al regresar de sus vacaciones, las computadoras siguen negociando. 


* Como nombres de los animales se han elegido Woofer y Tweeter, términos con los que, en inglés, se 
designa los parlantes de un sistema de estéreo; woofer significa "altavoz para frecuencias bajas" y tweeter 
"altavoz para altas frecuencias". (N. del autor, A. S. W.) 
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¿Por qué? ¿Puede haberse creado un bloqueo mutuo? ¿Es posible que se haya creado inanición (una 
espera eterna)? Explique. 

20. Se emplea el formato de mensajes de la Fig. 3-15 para enviar mensajes de petición a los controladores 
en software de dispositivos por bloques. ¿Cuáles campos, si acaso, podrían omitirse en los mensajes 
destinados a dispositivos por caracteres? 

21. Un controlador en software de disco duro recibe peticiones para los cilindros 10, 22, 20, 2, 40, 6 y 38, 
en ese orden. El brazo tarda 6 ms en moverse de un cilindro al siguiente. ¿Cuánto üempo de búsqueda se 
requiere para que 

(a) El primero que llegue, primero que se atienda? 

(b) Siga el cilindro más cercano? 

(c) Se aplique el algoritmo del elevador (moviéndose inicialmente hacia arriba)? 

En todos los casos, el brazo está inicialmente en el cilindro 20. 

22. Un vendedor de computadoras personales, en una visita a una universidad del suroeste de Amsterdam, 
comentó durante su "discurso" de venta que su compañía se había esforzado mucho por hacer que su 
versión de UNIX fuera muy rápida. Como ejemplo, citó que su controlador en software de disco usaba el 
algoritmo del elevador y también ponía en cola múltiples peticiones para el mismo cilindro en orden por 
sector. Un estudiante, Harry Hacker, quedó impresionado y compró una computadora, la llevó a casa, y 
escribió un programa que leía directamente 10 000 bloques dispersos por todo el disco. Para su asombro, 
el rendimiento que midió fue idéntico al que se esperaría si se utilizara el régimen de primero que llega, 
primero que se atiende. ¿Estaba mintiendo el vendedor? 

23. Un proceso UNIX tiene dos partes, la parte del usuario y la parte del kemel. ¿La parte del kemel es 
como una subrutina o como una corrutina? 

24 El manejador de interrupciones de reloj de cierta computadora requiere 2 ms (incluido el gasto extra 
de conmutación de procesos) por tic del reloj. El reloj opera a 60 Hz. ¿Qué fracción de la CPU está 
dedicada al reloj? 

25. En el texto se dieron dos ejemplos de temporizador de vigilancia: temporizar el arranque del motor del 
disco flexible y dar tiempo para el retomo de carro en las terminales de copia impresa. Cite un tercer 
ejemplo. 

26. Las term in ales RS-232 se controlan por interrupciones, no así las ter mi nales mapeadas en la 
memoria.¿Por qué? 

27. Considere el funcionamiento de una terminal. El controlador envía a la salida un carácter y luego se 
bloquea. Una vez que se ha exhibido el carácter, ocurre una interrupción y se envía un mensaje al 
controlador bloqueado, que envía a la salida el siguiente carácter y se bloquea otra vez. Si el tiempo 
necesario para pasar un mensaje, enviar un carácter a la salida y bloquearse es de 4 ms, ¿funciona bien 
este método en líneas de 110 bauds? ¿Y en líneas de 4800 bauds? 

28. Una terminal de mapa de bits contiene 1200 por 800 pixeles. Para desplazar una ventana, la CPU (o el 
controlador en hardware) debe mover todas las líneas de texto hacia arriba copiando sus bits de una parte de la 
RAM de video a otra. Si una ventana dada tiene 66 líneas de altura y 80 caracteres de ancho (5280 caracteres 
en total) y el espacio que un carácter ocupa tiene 8 pixeles de ancho por 12 pixeles de altura, ¿qué tiempo tarda 
en desplazarse toda la ventana con una rapidez de copiado de 500 ns por byte? Si todas las líneas tienen 80 
caracteres de longitud, calcule la tasa de datos equivalente de la terminal en bauds. Se requieren 50 
microsegundos para colocar un carácter en la pantalla. Calcule ahora la tasa en bauds para la misma terminal 
en color, con 4 bits/pixel. (Ahora se requieren 200 microsegundos para colocar un carácter en la pantalla.) 
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29. ¿Por qué los sistemas operativos proporcionan caracteres de escape, como CTRL-V en MINIX? 

30 . Después de recibir un carácter DEL (SIGINT), el controlador de MINIX desecha todas las salidas que 
actualmente están en cola para esa terminal. ¿Por qué? 

31 . Muchas terminales RS-232 tienen secuencias de escape para borrar la línea actual y subir una línea 
todas las líneas que están abajo de ella. ¿Cómo cree usted que esta capacidad se implemente dentro de la 
terminal? 

32 . En la pantalla a color de la IBM PC original, la escritura en la RAM de video en cualquier momento 
que no fuera durante el retrazado vertical del haz del CRT causaba la aparición de feas manchas por toda 
la pantalla. Una imagen de pantalla tenía 25 por 80 caracteres, cada uno de los cuales cabía en un cuadro 
de 8 por 8 pixeles. Cada fila de 640 pixeles se dibujaba durante un solo barrido horizontal del haz, que 
tardaba 63.6 microsegundos, incluido el retrazado horizontal. La pantalla se redibujaba 60 veces por 
segundo, y en cada ocasión se requería un periodo de retrazado vertical para colocar el haz otra vez al 
principio de la pantalla. ¿Qué fracción del tiempo está la RAM de video disponible para escribir en ella? 

33. Escriba un controlador de gráficos para la pantalla IBM a color, o alguna otra pantalla de mapa de bits 
adecuada. El controlador deberá aceptar comandos para encender y apagar pixeles individuales, desplazar 
rectángulos dentro de la pantalla y cualesquier otras capacidades que le resulten interesantes. Los 
programas de usuario se comunican con el controlador abriendo /dev/graphics y escribiendo comandos en 
él. 

34 . Modifique el controlador en software de disquete de MINIX de modo que guarde en caché una pista a 
la vez. 

35 . Implemento un controlador de disco flexible que opere como dispositivo por caracteres, no de bloques, 
a fin de pasar por alto el caché de bloques del sistema de archivos. De este modo, los usuarios pueden leer 
grandes porciones de datos del disco, que se envían por DMA directamente al espacio del usuario, 
mejorando considerablemente el rendimiento. Este controlador sería de interés primordialmente para os 
programas que necesitan leer los bits en bruto del disco, sin tener en cuenta el sistema de archivos. Los 
verificadores de sistemas de archivos pertenecen a esta categoría. 

36 . Implemento la llamada al sistema PROFIL de UNIX, que no está presente en MINIX. 

37 . Modifique el controlador de la terminal de modo que, además de tener una tecla especial para borrar el 
carácter anterior, cuente con una tecla para borrar la palabra anterior. 

38 . Se agregó a un sistema MINIX un nuevo dispositivo de disco duro con medios removibles. Este 
dispositivo debe acelerarse hasta adquirir la velocidad de operación cada vez que se cambian los medios, y 
el tiempo que toma esto es considerable. Se anticipa que los medios se cambiarán con frecuencia mi entras 
el sistema está operando. Esto hace que la rutina waitfor de at wini.c ya no sea satisfactoria. Diseñe una 
nueva rutina waitfor en la que, si el patrón de bits que se espera no se encuentra después de un segundo de 
espera activa, se ingrese en una fase en la que la tarea de disco dormirá durante 1 s, probará el puerto y se 
dormirá de nuevo durante otro segundo hasta que se encuentre el patrón buscado o expire el periodo de 
espera preestablecido T1MEOUT. 
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ADMINISTRACIÓN DE MEMORIA 


La memoria es un recurso importante que se debe administrar con cuidado. Si bien hoy día la 
computadora casera media tiene cincuenta veces más memoria que la IBM 7094, que era la computadora 
más grande en el mundo a principios de los años sesenta, los programas están aumentando de tamaño con 
tanta rapidez como las memorias. Parafraseando la ley de Parkinson, "los programas se expanden hasta 
llenar la memoria disponible para contenerlos". En este capítulo estudiaremos la forma en que los sistemas 
operativos administran su memoria. 

Idealmente, lo que a todo programador le gustaría es una memoria infinitamente grande y rápida 
que además no sea volátil, es decir, que no pierda su contenido cuando se interrumpa la alimentación 
eléctrica. Ya entrados en materia, ¿por qué no pedimos también que sea económica? Desafortunadamente, 
la tecnología no proporciona tales memorias. En consecuencia, la mayor parte de las computadoras tienen 
una jerarquía de memoria, con una cantidad pequeña de memoria caché muy rápida, costosa y volátil, 
algunos megabytes de memoria principal (RAM) volátil de mediana velocidad y mediano precio, y cientos 
o miles de megabytes de almacenamiento en disco lento, económico y no volátil. Corresponde al sistema 
operativo coordinar el uso de estas memorias. 

La parte del sistema operativo que administra la jerarquía de memoria se denomina administrador 
de memoria. Su trabajo consiste en mantenerse al tanto de qué partes de la memoria |t8tánenuso y cuáles 
no lo están, asignar memoria a los procesos cuando la necesitan y recuperarla | cuando terminan, y 
controlar el intercambio entre la memoria principal y el disco cuando la Ipnmera es demasiado pequeña 
para contener todos los procesos. 

En este capítulo investigaremos varios esquemas de manejo de memoria distintos, que van desde 
los muy sencillos hasta los muy avanzados. Comenzaremos por el principio y examinare- 
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mos primero el sistema de administración de memoria más sencillo posible, para avanzar gradualmente a 
sistemas cada vez más complicados. 


4.1 ADMINISTRACIÓN BÁSICA DE MEMORIA 


Los sistemas de administración de memoria se pueden dividir en dos clases, los que trasladan procesos 
entre la memoria y el disco durante la ejecución (intercambio y paginación) y los que no lo hacen. Estos 
últimos son más sencillos, así que los estudiaremos primero. Más adelante en el capítulo examinaremos el 
intercambio y la paginación. A lo largo de todo este capítulo, el lector debe tener presente que el 
intercambio y la paginación son en buena medida situaciones causadas por la falta de suficiente memoria 
principal para contener todos los programas a la vez. Al bajar el costo de la memoria principal, los 
argumentos a favor de un tipo de esquema de administración de memoria u otro pueden hacerse obsoletos, 
a menos que los programas crezcan con mayor rapidez que las memorias. 


4.1.1 MONOPROGRAMACIÓN SIN INTERCAMBIO NI PAGINACIÓN 


El esquema de administración de memoria más sencillo posible es ejecutar sólo un programa a la vez, 
compartiendo la memoria entre ese programa y el sistema operativo. En la Fig. 4-1 se muestran tres 
variaciones sobre este tema. El sistema operativo puede estar en la base de la memoria en RAM (memoria 
de acceso aleatorio), como se muestra en la Fig. 4-1 (a), o puede estar en ROM (memoria sólo de lectura) 
en la parte superior de la memoria, como en la Fig. 4-l(b), o lo» controladores de dispositivos pueden estar 
en la parte superior de la memoria en una ROM con el resto del sistema en RAM hasta abajo, como se 
muestra en la Fig. 4-l(c). Este último modelo es utilizado por los sistemas MS-DOS pequeños, por 
ejemplo. En las IBM PC, la porción del sistema que está en ROM se llama BIOS (Basic Input Output 
System, sistema básico de entrada salida). 
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Figura 4-1. Tres formas sencillas de organizar la memoria con un sistema operativo y un 
proceso de usuario. También existen otras posibilidades. 


Si el sistema está organizado de esta manera, sólo puede ejecutarse un proceso a la vez. Tan 
pronto como el usuario teclea un comando, el sistema operativo copia el programa solicitador 
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disco a la memoria y lo ejecuta. Cuando el proceso termina, el sistema operativo exhibe un carácter de 
indicación y espera un nuevo comando. Cuando el sistema operativo lo recibe, carga un nuevo programa 
en la memoria, sobreescribiendo el primero. 


4,1,2 Multiprogramación con particiones fijas 


Aunque a veces se usa la monoprogramación en computadoras pequeñas con sistemas operativos 
sencillos, hay muchos casos en que es deseable permitir la ejecución de múltiples procesos a la vez. En los 
sistemas de tiempo compartido, tener varios procesos en la memoria a la vez implica que cuando un 
proceso está bloqueado esperando que termine una E/S, otro puede usar la CPU. Así, la 
multiprogramación aumenta el aprovechamiento de la CPU. Sin embargo, incluso en computadoras 
personales hay ocasiones en las que resulta útil poder ejecutar dos o más programas a la vez. 

La forma más fácil de lograr la multiprogramación consiste simplemente en dividir la memoria en 
n particiones, posiblemente desiguales. Esta división puede, por ejemplo, efectuarse manualmente cuando 
se inicia el sistema. 

Cuando llega un trabajo, se le puede colocar en la cola de entrada de la partición pequeña que 
puede contenerlo. Puesto que las particiones están fijas en este esquema, cualquier espacio de una 
partición que un trabajo no utilice se desperdiciará. En la Fig. 4-2(a) vemos el aspecto que tiene este 
sistema de particiones fijas y colas de entrada individuales. 


Múlteles colas 



Figura 4-2. (a) Particiones de memoria fijas con colas de entrada individuales para cada 
partición, (b) Particiones de memoria fija con una sola cola de entrada. 

La desventaja de repartir los trabajos entrantes en colas distintas se hace evidente cuando la cola 
de una partición grande está vacía pero la cola de una partición pequeña está llena, como es 
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el caso de las particiones 1 y 3 en la Fig. 4-2(a). Una organización alternativa sería mantener una sola 
cola, como en la Fig. 4-2(b). Cada vez que se libera una partición, se selecciona el trabajo más cercano a 
la cabeza de la cola que cabe en esa partición, se carga en dicha partición y ejecuta. Puesto que no es 
deseable desperdiciar una partición grande en un trabajo pequeño, un estrategia diferente consiste en 
examinar toda la cola de entrada cada vez que se libera una partición y escoger el trabajo más grande que 
cabe en ella. Observe que este último algoritmo discrimina contra los trabajos pequeños, considerándolos 
indignos de recibir toda la partición, en tanto que usualmente es deseable dar el mejor servicio, y no el 
peor, a los trabajos más pequeños (que supuestamente son interactivos). 

Una salida consiste en tener por lo menos una partición pequeña disponible. Una partición a 
permitirá que se ejecuten los trabajos pequeños sin tener que asignar una partición grande para ello. Otro 
enfoque sería adoptar la regla de que un trabajo que es elegible para ejecutarse no puede pasarse por alto 
más de k veces. Cada vez que se pase por alto, el trabajo recibirá un punto, cuando haya adquirido k 
puntos, no se le podrá pasar por alto otra vez. 

Este sistema, con particiones fijas establecidas por el operador en la mañana y que no se 
modificaban posteriormente, fue utilizado por OS/360 en macrocomputadoras de IBM durante muchos 
años. Se le llamaba MFT (multiprogramación con un número fijo de tareas, u OS/MFT). Este sistema es 
fácil de entender e igualmente sencillo de implementar: los trabajos entrantes se ponen en cola hasta que 
está disponible una partición apropiada. En ese momento, el trabajo se carga en esa partición y se ejecuta 
hasta terminar. Hoy día son pocos los sistemas operativos que dan soporte a este modelo, si es que todavía 
existe alguno. 


Relocalización y protección 


La multiprogramación introduce dos problemas esenciales que es preciso resolver: la relocalización y la 
protección. Examinemos la Fig. 4-2. Es evidente que diferentes trabajos se ejecutarán en diferentes 
direcciones. Cuando se vincula un programa (es decir, cuando el programa principal, los procedimientos 
escritos por el usuario y los procedimientos de biblioteca se combinan en mi solo espacio de direcciones), 
el vinculador necesita saber en qué dirección de la memoria va a comenzar el programa. 

Por ejemplo, supongamos que la primera instrucción es una llamada a un procedimiento que está 
en la dirección absoluta 100 dentro del archivo binario producido por el vinculador. Si este programa se 
carga en la partición 1, esa instrucción saltará a la dirección absoluta 100, que está, dentro del sistema 
operativo. Lo que se necesita es una llamada a 100K + 100. Si el programa se le carga en la partición 2, 
deberá efectuarse como una llamada a 200K + 100, etc. Este problemas se denomina problema de 
relocalización. 

Una posible solución es modificar realmente las instrucciones en el momento en que el programa 
se carga en la memoria. Se suma 100K a cada una de las direcciones de un programa que se carga en la 
partición 1, se suma 200K a las direcciones de los programas cargados en la partición 2, etc. A fin de 
efectuar la relocalización durante la carga de esta manera, el vinculador debe incluir en el programa 
binario una lista o mapa de bits que indique cuáles palabras del programa son direcciones que deben 
relocalizarse y cuáles con códigos de operación, constantes 
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u otros elementos que no deben relocalizarse. OS/MFT funcionaba de este modo. Algunas 
microcomputadoras también trabajan así. 

La relocalización durante la carga no resuelve el problema de la protección. Un programa mal 
intencionado siempre puede construir una nueva instrucción y saltar a ella. Dado que los programas en 
este sistema usan direcciones de memoria absolutas en lugar de direcciones relativas a un registro, no hay 
forma de impedir que un programa construya una instrucción que lea o escriba cualquier palabra de la 
memoria. En los sistemas multiusuario, no es conveniente permitir que los procesos lean y escriban en 
memoria que pertenece a otros usuarios. 

La solución que IBM escogió para proteger el 360 fue dividir la memoria en bloques de 2K bytes 
y asignar un código de protección de cuatro bits a cada bloque. La PSW contenía una clave de cuatro bits. 
El hardware del 360 atrapaba cualquier intento, por parte de un proceso en ejecución, de acceder a 
memoria cuyo código de protección difería de la clave de la PSW. Puesto que sólo el sistema operativo 
podía cambiar los códigos de protección y la clave, los procesos de usuario no podían interferirse ni 
interferir el sistema operativo mismo. 

Una solución alternativa tanto al problema de relocalización como al de protección consiste en 
equipar la máquina con dos registros especiales en hardware, llamados registros de base y de lí mi te. 
Cuando se calendariza un proceso, el registro de base se carga con la dirección del principio de su 
partición, y el registro de límite se carga con la longitud de la partición. A cada dirección de memoria 
generada se le suma automáticamente el contenido del registro de base antes de enviarse a la memoria. De 
este modo, si el registro de base es de 100K, una instrucción CALL 100 se convierte efectivamente en una 
instrucción CALL 100K + 100, sin que la instrucción en sí se modifique. Además, las direcciones se 
cotejan con el registro de límite para asegurar que no intenten acceder a memoria fuera de la partición 
actual. El hardware protege los registros de base y de límite para evitar que los programas de usuario los 
modifiquen. 

La CDC 6600 —la primera supercomputadora que hubo en el mundo— utilizaba este esquema. La 
CPU Intel 8088 empleada para la IBM PC original utilizaba una versión más débil de este esquema: 
registros de base, pero sin registros de límite. A partir de la 286, se adoptó un mejor esquema. 


4.2 INTERCAMBIO 


En un sistema por lotes, la organización de la memoria en particiones fijas es sencilla y efectiva. Cada 
trabajo se carga en una partición cuando llega al frente de la cola, y permanece en la memo-ria hasta 
terminar. En tanto sea posible mantener en la memoria suficientes trabajos para mantener ocupada a la 
CPU todo el tiempo, no hay por qué usar algo más complicado. 

En los sistemas de tiempo compartido o las computadoras personales orientadas a gráficos, la 
situación es diferente. A veces no hay bastante memoria principal para contener todos los procesos que 
están activos actualmente, y los procesos en exceso deben mantenerse en disco y traerse dinámicamente 
para que se ejecuten. 

Podemos usar dos enfoques de administración de memoria generales, dependiendo (en parte) del 
hardware disponible. La estrategia más sencilla, llamada intercambio, consiste en traer a la 
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memoria cada proceso en su totalidad, ejecutarlo durante un tiempo, y después colocarlo otra vez en el 
disco. La otra estrategia, llamada memoria virtual, permite a los programas ejecutarse aunque sólo estén 
parcialmente en la memoria principal. A continuación estudiaremos el intercambio; en la sección 4.3 
examinaremos la memoria virtual. 

El funcionamiento de un sistema con intercambio se ilustra en la Fig. 4-3. Inicialmente, sólo el 
proceso A está en la memoria. Luego se crean o se traen del disco los procesos B y C. En la Fig. 4-3(d) A 
termina o se intercambia al disco. Luego llega D y B sale. Por último, entra E. 

Tiempo—>- 

mm 

c 


D 

Sistema 

operativo 

(a) (b) (c) <d> (e) (t) <g) 

Figura 4-3. La asignación de memoria cambia conforme los procesos entran en la memoria y 
salen de ella. Las regiones sombreadas son memoria no utilizada. 



La diferencia principal entre las particiones fijas de la Fig. 4-2 y las particiones variables de la Fig. 
4-3 es que el número, ubicación y tamaño de las particiones varían dinámicamente en el segundo caso 
conforme los procesos vienen y van, mientras que en el primer caso están fijas. La flexibilidad de no estar 
atado a un número fijo de particiones que podrían ser demasiado grandes o demasiado pequeñas mejora el 
aprovechamiento de la memoria, pero también complica la asignación y liberación de memoria, así como 
su contabilización. 

Si el intercambio crea múltiples agujeros en la memoria, es posible combinarlos todos para formar 
uno grande desplazando todos los procesos hacia abajo hasta donde sea posible. Esta técnica se conoce 
como compactación de memoria, y pocas veces se practica porque requiere mucho tiempo de CPU. Por 
ejemplo, en una máquina de 32MB que puede copiar 16 bytes por microsegundo tomaría 2 segundos 
compactar toda la memoria. 

Un punto que cabe destacar se refiere a la cantidad de memoria que debe asignarse a un proceso 
cuando se crea o se trae a la memoria. Si los procesos se crean con un tamaño fijo que nunca cambia, la 
asignación es sencilla: se asigna exactamente lo que se necesita, ni más ni menos. 

En cambio, si los segmentos de datos de los procesos pueden crecer, por ejemplo, mediante 
asignación dinámica de memoria desde un montículo, como en muchos lenguajes de programación, 
ocurrirá un problema cada vez que un proceso trate de crecer. Si hay un agujero adyacente 
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al proceso, se le puede asignar y el proceso podrá crecer hacia el agujero. Por otro lado, si el proceso está 
adyacente a otro proceso, el proceso en crecimiento tendrá que ser transferido a un agujero en la memoria 
que tenga el tamaño suficiente para contenerlo, o bien uno o más procesos tendrán que ser intercambiados 
a disco para crear un agujero del tamaño necesario. Si un proceso no puede crecer en la memoria, y el área 
de intercambio en el disco está llena, el proceso tendrá que esperar o morir. 

Si se espera que la mayor parte de los procesos crezcan durante su ejecución, probablemente será 
conveniente asignar un poco de memoria adicional cada vez que se traiga un proceso a la memoria o se le 
cambie de lugar, a fin de reducir el gasto extra asociado al traslado o intercambio de procesos que ya no 
caben en la memoria que se les asignó. Sin embargo, al intercambiar los procesos al disco, sólo debe 
intercambiarse la memoria que se está utilizando realmente; sería un desperdicio intercambiar también la 
memoria adicional. En la Fig. 4-4(a) vemos una configuración de memoria en la que se asignó a dos 
procesos espacio para crecer. 


| Espacio para crecer 


j Espacio para creoer 


Figura 4-4. (a) Asignación de espacio para un segmento de datos que crece, (b) Asignación de 
espacio para una pila que crece y un segmento de datos que crece. 
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Si los procesos pueden tener dos procesos en crecimiento, por ejemplo, el segmento de datos que 
se está usando como montículo para variables que se asignan y liberan dinámicamente, y un segmento de 
pila para las variables locales normales y las direcciones de retomo, podemos tener > ana organización 
alternativa, que se ilustra en la Fig. 4-4(b). En esta figura vemos que cada yoceso tiene una pila en la 
parte superior de su memoria asignada que está creciendo hacia abajo, y un segmento de datos justo 
después del texto del programa, creciendo hacia arriba. La memoria que está entre los dos segmentos se 
puede destinar a cualquiera de ellos. Si el espacio se agota, el proceso tendrá que ser transferido a un 
agujero con suficiente espacio, intercambiarse a disco hasta que pueda crearse un agujero del tamaño 
suficiente, o ter mi narse. 
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4.2.1 Administración de memoria con mapas de bits 


Cuando la memoria se asigna dinámicamente, el sistema operativo debe administrarla. En términos 
generales, hay dos formas de contabilizar la utilización de memoria: mapas de bits y listas libres. En esta 
sección y en la siguiente examinaremos estos dos métodos por tumo. 

Con un mapa de bits, la memoria se divide en unidades de asignación, tal vez sólo de unas cuantas 
palabras o quizá de varios kilobytes. A cada unidad de asignación corresponde un bit del mapa de bits, que 
es 0 si la unidad está libre y 1 si está ocupada (o viceversa). En la Fig. 4-5 se muestra una parte de la 
memoria y el mapa de bits correspondiente. 



Figura 4-5. (a) Una parte de la memoria con cinco procesos y tres agujeros. Las marcas 
indican las unidades de asignación de memoria. Las regiones sombreadas (O en el mapa de bits) 
están libres, (b) El mapa de bits correspondiente, (e) La misma información en forma de lista. 


El tamaño de la unidad de asignación es una cuestión de diseño importante. Cuanto menor sea la 
unidad de asignación, mayor será el mapa de bits. Sin embargo, incluso con una unidad de asignación de 
sólo cuatro bits, 32 bits de memoria sólo requerirán un bit del mapa. Una memoria de 32n bits usará n bits 
de mapa, y el mapa sólo ocupará 1/33 de la memoria. Si se escoge una unidad de asignación grande, el 
mapa de bits será más pequeño, pero podría desperdiciarse una cantidad apreciable de memoria en la 
última unidad si el tamaño del proceso no es un múltiplo exacto de la unidad de asignación. 

Un mapa de bits ofrece un método sencillo para contabilizar las palabras en una cantidad fija de 
memoria, porque el tamaño del mapa de bits depende sólo del tamaño de la memoria y del tamaño de la 
unidad de asignación. El problema principal que presenta es que una vez que se ha decidido traer a la 
memoria un proceso de k unidades, el administrador de memoria debe buscar en el mapa de bits una serie 
de k bits en O consecutivos. La búsqueda de series de una longitud dada en un mapa de bits es una 
operación lenta (porque la serie puede cruzar fronteras de palabra en el mapa); éste es un argumento en 
contra de los mapas de bits. 
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4.2.2 Administración de memoria con listas enlazadas 


Otra forma de contabilizar la memoria es mantener una lista enlazada de segmentos de memoria libres y 
asignados, donde un segmento es un proceso o bien un agujero entre dos procesos. La memoria de la Fig. 
4-5(a) se representa en la Fig. 4-5(c) como lista enlazada de segmentos. Cada entrada de la lista especifica 
un agujero (H) o un proceso (P), la dirección en la que principia, la longitud y un apuntador a la siguiente 
entrada. 


En este ejemplo, la lista de segmentos se mantiene ordenada por dirección. Este ordenamiento 
tiene la ventaja de que cuando un proceso termina o es intercambiado a disco, es fácil actualizar la lista. 
Un proceso que ter mi na normalmente tiene dos vecinos (excepto cuando está en el tope o la base de la 
memoria). Éstos pueden ser procesos o agujeros, dando lugar a las cuatro combinaciones de la Fig. 4-6. En 
la Fig. 4-6(a) la actualización de la lista requiere la sustitución de una P por una H. En las Figs. 4-6(b) y 4- 
6(c) dos entradas se funden para dar una sola, y el tamaño de la lista se reduce en una entrada. En la Fig. 
4-6(d) tres entradas se funden y dos elementos se eliminan de la lista. Puesto que la ranura de tabla de 
procesos para el proceso que va a terminar normalmente apunta a la entrada del proceso mismo en la lista, 
puede ser más recomendable tener una lista doblemente enlazada, en lugar de la lista con un solo enlace de 
la Fig. 4-5(c). Esta estructura facilita la localización de la entrada anterior para determinar si es posible 
una fusión. 


Antes de qua X termine Después de que X termine 

(a) [ A [ X | B | se convierte en | A ¡í%%¡ B | 

m I A I x Wfa •.»»*««, | a. 

w x I i I b | 

« x wm — mmm.m 

Figura 4-6. Cuatro combinaciones de vecinos para el proceso que termina, X. 


Si los procesos y agujeros se mantienen en una lista ordenada por dirección, se pueden usar varios 
algoritmos para asignar memoria a un proceso recién creado o traído a la memoria. Suponemos que el 
administrador de memoria sabe cuánta memoria debe asignar. El algoritmo más sencillo es el de primer 
ajuste. El administrador de memoria examina la lista de segmentos hasta encontrar un agujero con el 
tamaño suficiente. A continuación, el agujero se divide en dos fragmentos, uno para el proceso y otro para 
la memoria desocupada, excepto en el poco probable caso de que el ajuste sea exacto. El algoritmo de 
primer ajuste es rápido porque la búsqueda es la más corta posible. 

Una variante menor del primer ajuste es el siguiente ajuste. Este algoritmo funciona igual que el 
de primer ajuste, excepto que toma nota de dónde está cada vez que encuentra un agujero apropiado. La 
siguiente vez que se invoque, el algoritmo comenzará a buscar en la lista a partir del lugar donde se quedó 
la última vez, en lugar de comenzar por el principio, como hace el primer ajuste. Simulaciones ejecutadas 
por Bays (1977) demuestran que el siguiente ajuste ofrece un rendimiento ligeramente peor que el primer 
ajuste. 
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Otro algoritmo bien conocido es el de mejor ajuste, que examina toda la lista y toma el agujero 
más pequeño que es adecuado. En lugar de partir un agujero grande que podría necesitarse después, el 
mejor ajuste trata de encontrar un agujero con un tamaño cercano al que se necesita. 

Como ejemplo de primer ajuste y mejor ajuste, consideremos otra vez la Fig. 4-5. Si se requiere 
un bloque de tamaño 2, el primer ajuste asignará el agujero que está en 5, pero el mejor ajuste asignará el 
agujero que está en 18. 

El mejor ajuste es más lento que el primer ajuste porque debe examinar toda la lista cada vez que 
se invoca. Lo que resulta sorprendente es que también desperdicia más memoria que el primer ajuste o el 
siguiente ajuste porque tiende a llenar la memoria de pequeños agujeros inútiles. En promedio, el primer 
ajuste g ñera agujeros más grandes. 

A fin de sortear el problema de partir un agujero con un tamaño casi igual al requerido para 
obtener un área asignada al proceso y un agujero diminuto, podríamos considerar el peor ajuste, es decir, 
tomar siempre el agujero más grande disponible, de modo que el agujero sobrante tenga un tamaño 
suficiente para ser útil. Las simulaciones han demostrado que el peor ajuste tampoco es una idea muy 
buena. 


Los cuatro algoritmos pueden agilizarse manteniendo listas separadas de procesos y agujeros. De 
este modo, los algoritmos dedican toda su energía a inspeccionar agujeros, no procesos. El inevitable 
precio que se paga por esta agilización de la asignación es la complejidad adicional y la lentitud del 
proceso de liberar memoria, ya que es preciso quitar un segmento liberado de la lista de procesos e 
insertarlo en la lista de agujeros. 

Si se mantienen listas aparte para los procesos y los agujeros, la lista de agujeros puede 
mantenerse ordenada por tamaño, a fin de hacer más rápido el algoritmo de mejor ajuste. Si este algoritmo 
examina una lista de agujeros del más pequeño al más grande, tan pronto como encuentre un agujero 
adecuado sabrá que dicho agujero es el más pequeño que se puede usar, y por tanto el mejor ajuste. No es 
necesario buscar más, como en el esquema de una sola lista. Si se tiene una lista de agujeros ordenada por 
tamaño, los algoritmos de primer ajuste y mejor ajuste son igualmente rápidos, y el de siguiente ajuste no 
tiene caso. 

Si los agujeros se mantienen en listas aparte de las de procesos, es posible una pequeña 
optimización. En lugar de tener un conjunto aparte de estructuras de datos para mantener la lista de 
agujeros, como se hace en la Fig. 4-5(c), se pueden usar los agujeros mismos. La primera palabra de cada 
agujero podría ser el tamaño del agujero, y la segunda, un apuntador a la siguiente entrada. Los nodos de 
la lista de la Fig. 4-5(c), que requieren tres palabras y un bit (P/H), ya no son necesarios. 

Otro algoritmo de asignación más es el de ajuste rápido, que mantiene listas por separa para 
algunos de los tamaños más comunes solicitados. Por ejemplo, se podría tener una tabla con n entradas, en 
la que la primera entrada es un apuntador a una lista de agujeros de 4K, la segunda entrada es un 
apuntador a una lista de agujeros de 8K, la tercera es un apuntador a una lista de agujeros de 12K, y así 
sucesivamente. Los agujeros de, digamos, 21K, podrían colocarse en la lista de 20K o en una lista especial 
de agujeros con tamaños poco comunes. Si se usa el ajuste rápido, la localización de un agujero del 
tamaño requerido es extremadamente rápida, pero se tiene la misma desventaja que tienen todos los 
esquemas que ordenan por tamaño de agujero, a saber, que cuando un proceso termina o es intercambiado 
a disco la localización de sus vecinos 
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determinar si es posible una fusión es costosa. Si no se efectúan fusiones, la memoria pronto se 
fragmentará en un gran número de agujeros pequeños en los que no cabrá ningún proceso. 


4.3 MEMORIA VIRTUAL 


Hace muchos años las personas enfrentaron por primera vez programas que eran demasiado grandes para 
caber en la memoria disponible. La solución que normalmente se adoptaba era dividir el programa en 
fragmentos, llamados superposiciones. La superposición O era la primera que se ejecutaba. Al terminar, 
esta superposición llamaba a otra. Algunos sistemas de superposición eran muy complejos, pues permitían 
varias superposiciones en la memoria a la vez. Las superposiciones se mantenían en disco y el sistema 
operativo las intercambiaba con la memoria dinámicamente, según fúera necesario. 

Aunque el trabajo real de intercambiar las superposiciones corría por cuenta del sistema, la tarea 
de dividir el programa en fragmentos tenía que ser efectuada por el programador. La división de 
programas grandes en fragmentos modulares pequeños consumía tiempo y era tediosa. No pasó mucho 
tiempo antes de que a alguien se le ocurriera una forma de dejar todo el trabajo a la computadora. 

El método que se inventó (Eotheringham, 1961) se conoce ahora como memoria virtual. La idea 
en que se basa la memoria virtual es que el tamaño combinado del programa, los datos y la pila puede 
exceder la cantidad de memoria física disponible para él. El sistema operativo mantiene en la memoria 
principal las partes del programa que actualmente se están usando, y el resto en el disco. Por ejemplo, un 
programa de 16M puede ejecutarse en una máquina de 4M si se escogen con cuidado los 4M que se 
mantendrán en la memoria en cada instante, intercambiando segmentos del programa entre el disco y la 
memoria según se necesite. 

La memoria virtual también puede fúncionar en un sistema de multiprogramación, manteniendo 
segmentos de muchos programas en la memoria a la vez. Mientras un programa está esperando que se 
traiga a la memoria una de sus partes, está esperando E/S y no puede ejecutarse, así que puede otorgarse la 
CPU a otro proceso, lo mismo que en cualquier otro sistema de mulüprogramación. 


4.3.1 Paginación 


La mayor parte de los sistemas de memoria virtual emplean una técnica llamada paginación, que 
describiremos a continuación. En cualquier computadora, existe un conjunto de direcciones de memoria 
que los programas pueden producir. Cuando un programa ejecuta una instrucción como 


MOVE REG,1000 


está copiando el contenido de la dirección de memoria 1000 en REG (o viceversa, dependiendo de la 
computadora). Las direcciones pueden generarse usando indización, registros de base, registros de 
segmento y otras técnicas. 

Estas direcciones generadas por programas se denominan direcciones virtuales y constituyen el 
espacio de direcciones virtual. En las computadoras sin memoria virtual, la dirección 
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virtual se coloca directamente en el bus de memoria y hace que se lea o escriba la palabra de memoria 
física que tiene la misma dirección. Cuando se usa memoria virtual, las direcciones virtuales no pasan 
directamente al bus de memoria; en vez de ello, se envían a una unidad de administración de memoria 
(MMU), un chip o colección de chips que transforma las direcciones virtuales en direcciones de memoria 
física como se ilustra en la Fig. 4-7. 


La CPU envía direcciones 


virtuales a la MMU 



físicas a la memoria 

Figura 4-7. La posición y función de la MMU. 


En la Fig. 4-8 se muestra un ejemplo muy sencillo de cómo funciona esta transformación. En este 
ejemplo, tenemos una computadora que puede generar direcciones de 16 bits, desde 0 hasta 64K. Éstas 
son las direcciones virtuales. Esta computadora, empero, sólo tiene 32K de memoria física, así que si bien 
es posible escribir programas de 64K, no pueden cargarse enteros en la memoria y ejecutarse. Sin 
embargo, debe estar presente en el disco una copia completa de la imagen de núcleo del programa, que 
puede ser de hasta 64K, para poder traer a la memoria fragmento de ella según sea necesario. 

El espacio de direcciones virtual se divide en unidades llamadas páginas. Las unidades 
correspondientes en la memoria física se deno mi nan marcos de página. Las páginas y los marcos de 
página siempre tienen exactamente el mismo tamaño. En este ejemplo, ese tamaño es 4K, pero es común 
usar tamaños de página desde 512 bytes hasta 64K en los sistemas existentes. Con 64K de espacio de 
direcciones virtual y 32K de memoria física, tenemos 16 páginas virtuales y ocho marcos de página. Las 
transferencias entre la memoria y el disco siempre se efectúan en unidades de una página. 

Cuando el programa trata de acceder a la dirección O, por ejemplo, usando la instrucción 


MOVE REG,0 


la dirección virtual O se envía a la MMU. La MMU ve que esta dirección virtual queda en la página O (O 
a 4095) que, según su transformación, es el marco de página 2 (8192 a 12287). Por tanto, la MMU 
tansforma la dirección a 8192 y la coloca en el bus. La taijeta de memoria nada sabe de la MMU y 
simplemente ve una solicitud de leer o escribir en la dirección 8192, lo cual hace. 
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Figura 4-8. La relación entre las direcciones virtuales y las direcciones de la memoria física 
está dada por la tabla de páginas. 


Así, la MMU ha transformado efectivamente todas las direcciones virtuales entre O y 4095 en las 
direcciones físicas 8192 a 12287. 

De forma similar, una instrucción 


MO VEREG, 8192 
se transforma efectivamente en 


MOVE REG,24576 


porque la dirección virtual 8192 está en la página virtual 2 y esta página corresponde al marco de página 6 
(direcciones físicas 24576 a 28671). Como tercer ejemplo, la dirección virtual 20500 está 20 bytes 
después del inicio de la página virtual 5 (direcciones virtuales 20480 a 24575) y se transforma en la 
dirección física 12288 + 20 = 12308. 

En sí, esta capacidad para transformar las 16 páginas virtuales en cualquiera de los ocho marcos 
de página ajusfando el mapa de la MMU de la forma apropiada no resuelve el problema de que el espacio 
de direcciones virtual sea más grande que la memoria física. Puesto que sólo tenemos ocho marcos de 
página físicos, sólo ocho de las páginas virtuales de la Fig. 4-8 tendrán 
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correspondencia con la memoria física. Las demás, marcadas con una cruz en la figura, no se 
transformarán. En el hardware real, un bit de presente/ausente en cada entrada indica si la página tiene 
correspondencia o no. 

¿Qué sucede si el programa trata de usar una página sin correspondencia, por ejemplo, usando la 
instrucción 


MOVE REG,32780 


que es el byte 12 dentro de la página virtual 8 (que comienza en 32768)? La MMU se da cuenta de que la 
página no tiene correspondencia (esto se indica con una cruz en la figura) y hace que la CPU pase el 
control por una trampa al sistema operativo. Esta trampa se denomina falla de página. El sistema operativo 
escoge un marco de página poco utilizado y escribe su contenido de vuelta en el disco; luego trae la página 
a la que se hizo referencia y la coloca en el marco de página recién liberado, modifica el mapa, y reinicia 
la instrucción atrapada. 

Por ejemplo, si el sistema operativo decidiera desalojar el marco de página 1, cargaría la página 
virtual 8 en la dirección física 4K y haría dos cambios al mapa de la MMU. Primero, el sistema operativo 
marcaría la entrada de la página virtual 1 como sin correspondencia, a fin de atrapar cualesquier accesos 
futuros a las direcciones virtuales entre 4K y 8K; luego, reemplazaría la cruz de la entrada de la página 
virtual 8 por un 1, de modo que cuando la instrucción atrapada se vuelva a ejecutar transforme la dirección 
virtual 32780 en la dirección física 4108. 

Examinemos ahora el interior de la MMU para ver cómo funciona y por qué escogimos un tamaño 
de página que es una potencia de 2. En la Fig. 4-9 vemos un ejemplo de dirección virtual, 8196 
(0010000000000100 en binario), que se transforma usando el mapa de MMU de la Fig. 4-8. La dirección 
virtual de 16 bits entrante se divide en un número de página de cuatro bits y una distancia de 12 bits. Con 
cuatro bits para el número de página podemos representar 16 páginas, y con 12 bits para la distancia 
podemos direccionar los 4096 bytes contenidos en una página. 

El número de página se utiliza como índice de la tabla de páginas, produciendo el número del 
marco de página que corresponde a esa página virtual. Si el bit Presente/ausente es O, se genera una 
trampa al sistema operativo. Si el bit es 1, el número de marco de página que se encuentra en la tabla de 
páginas se copia en los tres bits de orden alto del registro de salida, junto con la distancia de 12 bits, que 
se copia sin modificación de la dirección virtual entrante. Juntas, estas dos partes forman una dirección 
física de 15 bits. A continuación el registro de salida se coloca en el bus de memoria como dirección de 
memoria física. 


4.3.2 Tablas de páginas 


En teoría, la transformación de direcciones virtuales en físicas se efectúa tal como lo hemos descrito. La 
dirección virtual se divide en un número de página virtual (bits de orden alto) y una distancia (bits de 
orden bajo). El número de página virtual sirve como índice para consultar la tabla de páginas y encontrar 
la entrada correspondiente a esa página virtual. En esa entrada se encuentra el número de marco de 
página, si lo hay, y este número se anexa al extremo de orden alto de la distancia, sustituyendo al número 
de página virtual y formando una dirección física que se puede enviar a la memoria. 
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Figura 4-9. Funcionamiento interno de la MMU con 16 páginas de 4K. 


El propósito de la tabla de páginas es transformar páginas virtuales en marcos de página. En 
términos matemáticos, la tabla de página es una función, con el número de página virtual como argumento 
y el número de marco físico como resultado. Usando el resultado de esta función, el campo de página 
virtual de una dirección virtual se puede sustituir por un campo de marco de página, formando así una 
dirección de memoria física. 

A pesar de lo sencillo de esta descripción, hay que resolver dos problemas importantes: 

1. La tabla de páginas puede ser extremadamente grande. 

2. La transformación debe ser rápida. 


El primer punto se sigue del hecho de que las computadoras modernas utilizan direcciones 
virtuales de por lo menos 32 bits. Con un tamaño de página de, digamos, 4K, un espacio de direcciones de 
32 bits tiene un millón de páginas, y un espacio de direcciones de 64 bits tiene más de las que nos 
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podamos imaginar. Con un millón de páginas en el espacio de direcciones virtual, la tabla páginas debe 
tener un millón de entradas. Y recordemos que cada proceso necesita su propia tabla de páginas. 

El segundo punto es consecuencia del hecho de que la transformación de virtual a física se debe 
efectuar en cada referencia a la memoria. Una instrucción típica tiene una palabra de instrucción, y con 
frecuencia también un operando en memoria. Por tanto, es necesario efectuar una, dos y a veces más 
referencias a la tabla de página por cada instrucción. Si una instrucción tarda, digamos, 10 ns, la búsqueda 
en la tabla de páginas debe efectuarse en unos cuantos nanosegundos para evitar que se convierta en un 
cuello de botella importante. 

La necesidad de transformar páginas grandes rápidamente es una restricción significativa sobre la 
forma de construir computadoras. Aunque el problema es más grave en el caso de las máquinas de mayor 
capacidad, también es importante en el extremo inferior, donde el costo y la relación precio/rendimiento 
son críticos. En esta sección y en las siguientes examinaremos el diseño de tablas de páginas con detalle y 
presentaremos varias soluciones de hardware que se han empleado en computadoras reales. 

El diseño más sencil'o (al menos en lo conceptual) es tener una sola tabla de páginas que consiste 
en un arreglo de registros en hardware rápidos, con una entrada para página virtual, indizado por número 
de página virtual. Cuando se inicia un proceso, el sistema operativo carga los registros con la tabla de 
páginas del proceso, tomada de una copia que se mantiene en la memoria principal. Durante la ejecución 
del proceso, no se requieren más referencias a la memoria para la tabla de páginas. Las ventajas de este 
método es que es sencillo y no requiere referencias a la memoria durante la transformación. Una 
desventaja es que el costo puede ser alto (si la tabla de páginas es grande). Tener que cargar la tabla de 
páginas en cada conmutación de contexto también puede perjudicar el rendimiento. 

En el otro extremo, la tabla de páginas puede estar toda en la memoria principal. En tal caso, todo 
lo que el hardware necesita es un solo registro que apunte al principio de la tabla. Este diseño permite 
modificar el mapa de memoria en una conmutación de contexto volviendo a cargar un registro. Desde 
luego, la desventaja es que se requiere una o más referencias a la memoria para leer las entradas de la tabla 
de página durante la ejecución de cada instrucción. Por esta razón este enfoque casi nunca se usa en su 
forma más pura, pero a continuación estudiaremos algunas variaciones que tienen un rendimiento muy 
superior. 


Tablas de páginas multínivel 


Con objeto de superar el problema de tener tablas de páginas enormes en la memoria todo el tiempo 
muchas computadoras usan una tabla de páginas multínivel. En la Fig. 4-10 se muestra un ejemplo 
sencillo. En la Fig. 4-10(a) tenemos una dirección virtual de 32 bits que se divide en un campo PT1 de 10 
bits, un campo PT2 de 10 bits y un campo Offset de 12 bits. Puesto que las distancias o desplazamientos 
(offsets) tienen 12 bits, las páginas son de 4K y hay un total de 2 20 de ellas. 

El secreto del método de tabla de páginas multínivel es evitar mantener todas las tablas de páginas 
en la memoria todo el tiempo, en particular, las tablas que no se necesiten no deben estar ahí. 
Supongamos, por ejemplo, que un proceso necesita 12 megabytes, los cuatro megabytes 
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Figura 4-10. (a) Dirección de 32 bits con dos campos de tabla de páginas, (b) Tablas de páginas de dos 
niveles. 


inferiores de la memoria para el texto del programa, los siguientes cuatro mcgabytcs para datos y los 
cuatro megabytes superiores para la pila. Entre la parte superior de los datos y la base de la pila hay un 
agujero gigantesco que no se usa. 

En la Fig. 4-10(b) vemos cómo la tabla de páginas de dos niveles funciona en este ejemplo. A la 
izquierda tenemos la tabla de páginas de nivel superior, con 1024 entradas, que corresponden al campo 
PT1 de 10 bits. Cuando se presenta una dirección virtual a la MMU, lo primero que hace es extraer el 
campo PT1 y usar este valor como índice para consultar la tabla de páginas de nivel superior. Cada una de 
estas 1024 entradas representa 4M porque todo el espacio de direcciones virtual de cuatro gigabytes (esto 
es, de 32 bits) se ha dividido en porciones de 1024 bytes. 
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La entrada que se ubica indizando en la tabla de páginas de nivel superior contiene la dirección o 
el número de marco de página de una tabla de páginas de segundo nivel. La entrada 0 de la tabla de 
páginas de nivel superior apunta a la tabla de páginas para el texto del programa, la entrada 1 apunta a la 
tabla de páginas para los datos, y la entrada 1023 apunta a la tabla de páginas para la pila. Las otras 
entradas (sombreadas) no se usan. Ahora se usa el campo PT2 como índice para consultar la tabla de 
páginas de segundo nivel seleccionada y encontrar el número de marco de página que corresponde a la 
página misma. 

Por ejemplo, consideremos la dirección virtual de 32 bits 0x00403004 (4 206 596 decimal), que 
está a una distancia de 12 292 bytes del principio de los datos. Esta dirección corresponde a PT1 = 1, PT2 
== 3 y Offset = 4. La MMU primero usa PT1 para consultar la tabla de páginas de nivel superior y obtener 
la entrada 1, que corresponde a las direcciones de 4M a 8M; luego, utiliza PT2 para consultar la tabla de 
páginas de segundo nivel que acaba de localizarse y extraer la entrada 3, que corresponde a las direcciones 
12288 a 16383 dentro de su trozo de 4M (o sea, las direcciones absolutas 4 206 592 a 4 210 687). Esta 
entrada contiene el número de marco de página de la página que contiene la dirección virtual 0x00403004. 
Si esa página no está en la memoria, el bit Presente/ausente de la entrada de la tabla de páginas será cero, 
y causará una falla de páginas de Si la página está en la memoria, el número de marco de página tomado 
de la tabla de páginas de segundo nivel se combina con la distancia (4) para construir una dirección física. 
Esta dirección se coloca en el bus y se envía a la memoria. 

El aspecto interesante de la Fig. 4-10 es que a pesar de que el espacio de direcciones contiene más 
de un millón de páginas, sólo se necesitan en realidad cuatro tablas de páginas: la tabla de nivel superior y 
las tablas de segundo nivel correspondientes a O a 4M, 4M a 8M y los 4M superiores. Los bits 
Presente/ausente de 1021 entradas de la tabla de páginas de nivel superior se ponen en O, forzando una 
falla de página si se accede a ellas. Si llega a ocurrir esto, el sistema operativo se dará cuenta de que el 
proceso está tratando de hacer referencia a memoria a la que no tiene autorización de acceder, y tomará las 
medidas apropiadas, como enviarle una señal o terminarlo. En este ejemplo escogimos números redondos 
para los diferentes tamaños y escogimos PT1 igual a PT2, pero desde luego en la práctica pueden usarse 
otros valores. 

El sistema de tablas de páginas de dos niveles de la Fig. 4-10 puede ampliarse a tres, cuatro o más 
niveles. Una mayor cantidad de niveles confiere más flexibilidad, pero es dudoso que la complejidad 
adicional se justifique más allá de los tres niveles. 

Pasemos ahora de la estructura macroscópica de las tablas de páginas a los detalles de una entrada de tabla 
de páginas. La organización exacta de una entrada depende en gran medida de la máquina, pero la clase de 
información presente es aproximadamente la misma en todas las máquinas. En la Fig. 4-11 presentamos 
un ejemplo de entrada de tabla de páginas. El tamaño varia de una computadora a otra, pero un tamaño 
común es de 32 bits. El campo más importante es el Número de marco de página. Después de todo, el 
objetivo de la transformación de páginas es localizar este valor. Junto a él tenemos el bit Presente/ausente. 
Si este bit es 1, la entrada es válida y puede usarse; si es O, la página virtual a la que la entrada pertenece 
no está actualmente en la memoria. El acceso a una entrada de tabla de páginas que tiene este bit en O 
causa una falla de página. 

Los bits de Protección indican qué clases de acceso están permitidas. En la forma más sencillla, 
este campo contiene un bit, y O significa lectura/escritura mi entras que 1 significa sólo lectura. 
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Figura 4-11. Entrada de tabla de páginas representativa. 


Una organización más compleja tendría tres bits, para habilitar la lectura, escritura y ejecución, 
respectivamente. 

Los bits Modificada y Referida siguen la pista al empleo de la página. Cuando se escribe en una 
página, el hardware automáticamente enciende el bit Modificada. Este bit es útil cuando el sistema 
operativo decide reutilizar un marco de página. Si la página que contiene ha sido modificada (es decir, está 
"sucia"), se deberá escribir de vuelta en el disco. Si la página no ha sido modificada (si está "limpia"), 
puede abandonarse, ya que la copia que está en el disco aún es válida. Este bit también se conoce como bit 
sucio, pues refleja el estado de la página. 

El bit Referida se enciende cada vez que se hace referencia a una página, sea para lectura o 
escritura. Su propósito es ayudar al sistema operativo a escoger la página que desalojará cuando ocurra 
una falla de página. Las páginas que no se están usando son mejores candidatos que las que están en uso, y 
este bit desempeña un papel importante en varios de los algoritmos de reemplazo de páginas que 
estudiaremos más adelante en este capítulo. 

El último bit permite inhabilitar la colocación en caché de la página. Esta capacidad es importante 
en el caso de páginas que corresponden a registros de dispositivos en lugar de memoria. Si el sistema 
operativo se queda dando vueltas en un ciclo esperando que un dispositivo de E/S responda a un comando 
que se le acaba de dar, es indispensable que el hardware continúe obteniendo la palabra del dispositivo y 
no use una copia vieja guardada en caché. Con este bit, puede desactivarse la colocación en caché. Las 
máquinas que tienen un espacio de E/S independiente y no usan E/S con mapa en la memoria no necesitan 
este bit. 


Adviértase que la dirección en disco en la que está guardada la página cuando no está en memoria 
no forma parte de la tabla de páginas. La razón es sencilla. La tabla de páginas contiene sólo la 
información que el hardware necesita para traducir una dirección virtual en una dirección física. La 
información que el sistema operativo necesita para manejar las fallas de página se mantiene en tablas de 
software dentro del sistema operativo. 


4.3.3 TLB — Buffers de consulta para traducción 


En la mayor parte de los esquemas de paginación, las tablas de páginas se mantienen en la memoria, 
debido a su gran tamaño. Esto puede tener un impacto enorme sobre el rendimiento. Consideremos, por 
ejemplo, una instrucción que copia un registro en otro. Si no hay paginación, esta instrucción sólo hace 
referencia a la memoria una vez, para obtener la instrucción. Si hay 
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paginación, se requieren referencias adicionales a la memoria para acceder a la tabla de páginas. Puesto 
que la velocidad de ejecución generalmente está limitada por la rapidez con que la CPU puede obtener 
instrucciones y datos de la memoria, tener que referirse dos veces a la tabla de páginas por cada referencia 
a la memoria reduce el rendimiento a una tercera parte. En estas condiciones, nadie usaría paginación. 

Los diseñadores de computadoras han estado al tanto de este problema desde hace años y han 
encontrado una solución. Su solución se basa en la observación de que muchos programas tienden a 
efectuar un gran número de referencias a un número pequeño de páginas, y no al revés. Así, sólo se lee 
mucho una fracción pequeña de las entradas de la tabla de páginas; el resto apenas si se usa. 

La solución que se encontró consiste en equipar las computadoras con un pequeño dispositivo de 
hardware para transformar las direcciones virtuales en físicas sin pasar por la tabla de páginas. El 
dispositivo, llamado TLB (buffer de consulta para traducción, en inglés, Translation Lookaside Buffer) o 
también memoria asociativa, se ilustra en la Fig. 4-12. Generalmente, el TLB está dentro de la MMU y 
consiste en un pequeño número de entradas, ocho en este ejemplo, pero pocas veces más que 64. Cada 
entrada contiene información acerca de una página; en particular, el número de página virtual, un bit que 
se enciende cuando la página se modifica, el código de protección (permisos de leer/escribir/ejecutar) y el 
marco de página físico en el que se encuentra la página. Estos campos tienen una correspondencia uno a 
uno con los campos de la tabla de páginas. Otro bit indica si la entrada es válida (si está en uso) o no. 


Válida 

Página virtual 

Modificada 

Protección 

Marco de página 

1 

140 

1 

RW 

31 

1 

20 

0 

RX 

38 

1 

130 

1 

RW 

29 

1 

129 

1 

RW 

62 

1 

19 

0 

RX 

50 

1 

21 

0 

RX 

45 

1 

860 

1 

RW 

14 

1 

861 

1 

RW 

75 


Figura 4-12. Un TLB para agilizar la paginación 


Un ejemplo que podría generar el TLB de la Fig. 4-12 es un proceso en un ciclo que abarca las 
páginas virtuales 19, 20 y 21, así que estas entradas del TLB tienen códigos de protección para leer y 
ejecutar. Los principales datos que se están usando (digamos, un arreglo que se está procesando) están en 
las páginas 129 y 130. La página 140 contiene los índices empleados en los cálculos del arreglo. Por 
último, la pila está en las páginas 860 y 861. 

Veamos ahora cómo fúnciona el TLB. Cuando se presenta una dirección virtual a la MMU para 
ser traducida, lo primero que hace el hardware es verificar si su número de página virtual 
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está presente en el TLB, comparándolo con todas las entradas simultáneamente (es decir, en paralelo). Si 
hay una concordancia válida y el acceso no viola los bits de protección, el marco de página se toma 
directamente del TLB, sin recurrir a la tabla de páginas. Si el número de página virtual está presente en el 
TLB pero la instrucción está tratando de escribir en una página sólo de lectura, se generará una falla de 
protección, tal como sucedería si se usara la tabla de páginas. 

El caso interesante es qué sucede si el número de página virtual no está en el TLB. La MMU 
detecta la falta de concordancia y realiza una búsqueda ordinaria en la tabla de páginas. A continuación 
desaloja una de las entradas del TLB y la sustituye por la entrada de tabla de páginas que encontró. Por 
tanto, si esa página se usa pronto otra vez, se le encontrará en el TLB. Cuando una entrada se desaloja del 
TLB, el bit de modificada se copia en su entrada de tabla de páginas en la memoria. Los demás valores ya 
están ahí. Cuando el TLB se carga de la tabla de páginas, se toman todos los campos de la memoria. 


Administración de TLB por software 


Hasta aquí, hemos supuesto que todas las máquinas con memoria virtual paginada tienen tablas de páginas 
reconocidas por el hardware, más un TLB. En este diseño, la administración del TLB y el manejo de fallas 
de TLB corren por cuenta exclusivamente del hardware de la MMU. Las trampas al sistema operativo sólo 
ocurren cuando una página no está en la memoria. 

En el pasado, este supuesto era cierto, pero algunas máquinas RISC modernas, incluidas MIPS, 
Alpha y HP PA, realizan casi toda esta administración de páginas en software. En estas máquinas, el 
sistema operativo carga explícitamente las entradas del TLB. Cuando no se encuentra una página virtual 
en el TLB, en lugar de que la MMU se remita simplemente a las tablas de páginas para encontrar y 
obtener la referencia de página requerida, genera una falla de TLB y deja que el sistema operativo se 
encargue del problema. Éste debe encontrar la página, eliminar una entrada del TLB, introducir la nueva y 
reiniciar la instrucción que falló. Y, desde luego, todo esto debe hacerse con unas cuantas instrucciones, 
porque las fallas de TLB podrían ocurrir con mucha mayor frecuencia que las fallas de página. 

Resulta sorprendente que, si el TLB tiene un tamaño razonable (digamos 64 entradas) para reducir 
la tasa de fallas, la administración por software del TLB es muy eficiente. La ganancia principal aquí es 
que la MMU es mucho más sencilla, lo que libera una cantidad considerable de área en el chip de la CPU 
para caches y otras características que pueden mejorar el rendimiento. Uhlig et al. (1994) estudian 
detalladamente la administración de TLB en software. 

Se han inventado diversas estrategias para mejorar el rendi mi ento en máquinas que realizan la 
administración de TLB en software. Un enfoque ataca tanto la reducción de las fallas de TLB como la 
reducción del costo de una falla de TLB cuando ocurre (Bala et al., 1994). A fin de reducir las fallas de 
TLB, el sistema operativo a veces puede usar su intuición para averiguar cuáles S páginas es probable que 
se usen a continuación y precargar sus entradas en el TLB. Por ejemplo, I cuando un proceso cliente 
efectúa un RPC para un proceso servidor en la misma máquina, es I muy probable que el servidor tenga 
que ejecutarse pronto. Sabiendo esto, al tiempo que procesa { la trampa para efectuar el RPC, el sistema 
puede averiguar dónde están las páginas de código, datos y pila del servidor, y traer sus entradas al TLB 
antes de que puedan causar fallas de TLB. 
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La forma normal de procesar una falla de TLB, sea en hardware o en software, es ir a la tabla de 
páginas y realizar las operaciones de indización necesarias para localizar la página a la que se hizo 
referencia. Lo malo de realizar esta búsqueda en software es que las páginas que contienen la tabla de 
páginas podrían no estar en el TLB, lo que causaría fallas de TLB adicionales durante el procesamiento. 
Estas fallas pueden reducirse manteniendo un caché grande (p. ej., 4K) en software de entradas de TLB en 
un lugar fijo cuya página siempre se mantiene en el TLB. Si primero se busca en el caché en software, el 
sistema operativo puede reducir sustancialmente las fallas de TLB. 


4.3.4 Tablas de páginas invertidas 


Las tablas de páginas tradicionales del tipo que hemos descrito hasta ahora requieren una entradas por 
cada página virtual, ya que están indizadas por número de página virtual. Si el espacio de direcciones 
consta de 232 bytes, con 4096 bytes por página, se necesitará más de un millón de entradas de tabla. 
Como mínimo, la tabla de páginas tendrá que ocupar 4 megabytes. En los sistemas grandes, este tamaño 
probablemente será manejable. 

Sin embargo, al hacerse cada vez más comunes las computadoras de 64 bits, la situación cambia 
drásticamente. Si el espacio de direcciones ahora tiene 264 bytes, con páginas de 4K, necesitaremos más 
de 1015 bytes para la tabla de páginas. Sacar de circulación un millón de gigabytes sólo para la tabla de 
páginas no es razonable, ni ahora, ni durante varias décadas más, sí es que alguna vez lo es. Por tanto, se 
requiere una solución distinta para los espacios de direcciones virtuales de 64 bits paginados. 

Una solución es la tabla de páginas invertida. En este diseño, hay una entrada por marco de página 
de la memoria real, no por cada página del espacio de direcciones virtual. Por ejemplo, con direcciones 
virtuales de 64 bits, páginas de 4K y 32MB de RAM, una tabla de páginas invertida sólo requiere 8192 
entradas. La entrada indica cuál (proceso, página virtual) está en ese marco de página. 

Aunque las tablas de páginas invertidas ahorran enormes cantidades de espacio, al menos cuando 
el espacio de direcciones virtual es mucho más grande que la memoria física, tienen una desventaja 
importante: la traducción de virtual a física se vuelve mucho más difícil. Cuando el proceso n hace 
referencia a la página virtual p, el hardware ya no puede encontrar la página física usando p como índice 
de la tabla de páginas. En vez de ello, debe buscar en toda la tabla de páginas invertida una entrada (n, p). 
Además, esta búsqueda debe efectuarse en cada referencia a la memoria, no sólo cuando hay una falla de 
página. Examinar una tabla de 8K cada vez que se hace referencia a la memoria no es la forma de hacer 
que una máquina sea vertiginosamente rápida. 

La solución a este dilema es usar el TLB. Si el TLB puede contener todas las páginas de uso 
pesado, la traducción puede efectuarse con tanta rapidez como con las tablas de páginas normales. Sin 
embargo, si ocurre una falla de TLB, habrá que examinar la tabla de páginas invertida. Si se usa una tabla 
de dispersión como índice de la tabla de páginas invertida, esta búsqueda puede hacerse razonablemente 
rápida. Ya se están usando tablas de páginas invertidas en algunas estaciones de trabajo IBM y Hewlett- 
Packard, y se harán más comunes conforme se generalice el uso de máquinas de 64 bits. 
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Se pueden encontrar otros enfoques para manejar memorias virtuales grandes en (Huck y Hays, 1993; 
Talluri y Hill, 1994; y Talluri et al., 1995). 

4.4 ALGORITMOS DE SUSTITUCIÓN DE PÁGINAS 

Cuando ocurre una falla de página, el sistema operativo tiene que escoger la página que sacará de la 
memoria para que pueda entrar la nueva página. Si la página que se eliminará fue modificada mientras 
estaba en la memoria, se debe reescribir en el disco a fin de actualizar la copia del disco, pero si no fue así 
(p. ej., si la página contenía texto de programa), la copia en disco ya estará actualizada y no será necesario 
reescribirla. La nueva página simplemente sobreescribe la que está siendo desalojada. 

Si bien sería posible escoger una página al azar para ser desalojada cuando ocurre una falla de 
página, el rendimiento del sistema es mucho mejor si se escoge una página que no se usa mucho. Si se 
eli mi na una página de mucho uso, probablemente tendrá que traerse pronto a la memoria otra vez, 
aumentando el gasto extra. Se ha trabajado mucho sobre el tema de los algoritmos de reemplazo de 
páginas, tanto teórica como experimentalmente. A continuación describimos algunos de los algoritmos 
más importantes. 

4.4.1 El algoritmo de sustitución de páginas óptimo 

El mejor algoritmo de reemplazo de páginas posible es fácil de describir pero imposible de implementar. 
En el momento en que ocurre una falla de páginas, algún conjunto de páginas está en la memoria. A una 
de estas páginas se hará referencia en la siguiente instrucción (la página que contiene esa instrucción). 
Otras páginas podrían no necesitarse sino hasta 10, 100 o tal vez 1000 instrucciones después. Cada página 
puede rotularse con el número de instrucciones que se ejecutarán antes de que se haga referencia a esa 
página. 

El algoritmo de reemplazo de páginas óptimo simplemente dice que se debe eliminar la página 
que tenga el rótulo más alto. Si una página no se va a usar sino hasta después de 8 millones de 
instrucciones y otra página no se usará sino hasta después de 6 millones de instrucciones, el desalojo de la 
primera postergará la falla de página que la traerá de nuevo a la memoria lo más lejos hacia el futuro que 
es posible. Las computadoras, al igual que las personas, tratan de aplazar los sucesos desagradables el 
mayor tiempo que se puede. 

El único problema con este algoritmo es que no se puede poner en práctica. En el momento en que 
ocurre la falla de página, el sistema operativo no tiene manera de saber cuándo se hará referencia a cada 
una de las páginas. (Vimos una situación similar antes con el algoritmo de planificación del primer trabajo 
más corto; ¿cómo puede el sistema saber cuál trabajo es el más corto?) No obstante, si se ejecuta un 
programa en un simulador y se toma nota de todas las referencias a páginas, es posible implementar el 
reemplazo de páginas óptimo en la segunda ejecución utilizando la información recabada durante la 
primera. 
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De este modo, es posible comparar el rendimiento de los algoritmos realizables con el mejor 
posible. Si un sistema operativo logra un rendimiento, digamos, sólo 1 % peor que el algoritmo óptimo, 
los esfuerzos dedicados a buscar un mejor algoritmo redundarán cuando más en una mejora del 1%. 

Para evitar confusiones, debemos dejar sentado que esta bitácora de referencias a páginas sólo es 
válido para el programa que acaba de medirse. El algoritmo de reemplazo de páginas derivado de él es 
específico para ése y sólo ese programa. Aunque este método es útil para evaluar los algoritmos de 
reemplazo de páginas, no sirve de nada en los sistemas prácticos. A continuación estudiaremos algoritmos 
que sí son útiles en los sistemas reales. 

4.4.2 El algoritmo de sustitución de páginas no usadas recientemente 

Para que el sistema operativo pueda recabar datos estadísticos útiles sobre cuáles páginas se están usando 
y cuáles no, la mayor parte de las computadoras con memoria virtual tienen dos bits de situación 
asociados a cada página. R se enciende cada vez que se hace referencia a la página (lectura o escritura). M 
se enciende cuando se escribe la página (es decir, se modifica). Los bits están contenidos en cada entrada 
de la tabla de páginas, como se muestra en la Fig. 4-11. Es importante darse cuenta de que estos bits se 
deben actualizar en cada referencia a la memoria, así que es vital que sea el hardware quien los ajuste. Una 
vez puesto en 1 un bit, seguirá siendo 1 hasta que el sistema operativo lo ponga en O en software. 

Si el hardware no tiene estos bits, pueden simularse como sigue. Cuando se inicia un proceso, 
todas sus entradas de la tabla de páginas se marcan como que no están en la memoria. Tan pronto como se 
haga referencia a cualquier página, ocurrirá una falla de página. Entonces, el sistema operativo enciende el 
bit R (en sus tablas intemas), modifica la entrada de la tabla de páginas de modo que apunte a la página 
correcta, con el modo SÓLO LECTURA, y reinicia la instrucción. Si subsecuentemente se escribe en la 
página, ocurrirá otra falla de página, lo que permitirá el sistema operativo encender el bit M y cambiar el 
modo de la página a LECTURA/ESCRITURA. 

Los bits R y M pueden servir para construir un algoritmo de paginación sencillo como sigue 
Cuando se inicia un proceso, el sistema operativo pone en O los dos bits de todas sus páginas 
Periódicamente (p. ej., en cada interrupción de reloj), se apaga el bit R, a fin de distinguir páginas a las 
que no se ha hecho referencia recientemente de las que sí se han leído. 

Cuando ocurre una falla de página, el sistema operativo examina todas las páginas y las divide en 
cuatro categorías con base en los valores actuales de sus bits R y M: 

Clase 0: no referida, no modificada. 

Clase 1: no referida, modificada. 

Clase 2: referida, no modificada. 

Clase 3: referida, modificada. 

Aunque a primera vista las páginas de clase 1 parecen imposibles, ocurren cuando una interrupción del 
reloj apaga el bit R de una página de clase 3. Las interrupciones de reloj no borran el bit M esta 
información se necesita para determinar si hay que reescribir en disco la página o no. 
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El algoritmo NRU (no utilizada recientemente) eli mi na una página al azar de la clase no vacía 
que tiene el número más bajo. Este algoritmo supone que es mejor eliminar una página modificada a la 
que no se ha hecho referencia en por lo menos un tic del reloj (por lo regular 20 ms) que una página limpia 
que no se está usando mucho. El atractivo principal de NRU es que es fácil de entender, eficiente de 
implementar y tiene un rendimiento que, si bien ciertamente no es óptimo, a menudo es adecuado. 

4.4.3 El algoritmo de sustitución de páginas de primera que entra, primera que sale (FIFO) 

Otro algoritmo de paginación con bajo gasto extra es el algoritmo FIFO (primera que entra, primera 
que sale). Para ilustrar su funcionamiento, consideremos un supermercado que tiene suficientes anaqueles 
para exhibir exactamente k productos distintos. Un día, alguna compañía introduce un nuevo alimento: 
yogurt orgánico liofilizado instantáneo que puede reconstituirse en un homo de microondas. Su éxito es 
inmediato, así que nuestro supermercado finito tiene que deshacerse de un producto viejo para poder tener 
el nuevo en exhibición. 

Una posibilidad consiste en encontrar el producto que el supermercado ha tenido en exhibición 
durante más tiempo (es decir, algo que comenzó a vender hace 120 años) y deshacerse de él bajo el 
supuesto de que a nadie le interesa ya. En efecto, el supermercado mantiene una lista enlazada de todos los 
productos que vende en el orden en que se introdujeron. El nuevo se coloca al final de la lista; el que está a 
la cabeza de la lista se elimina. 

Como algoritmo de reemplazo de páginas, puede aplicarse la misma idea. El sistema operativo 
mantiene una lista de todas las páginas que están en la memoria, siendo la página que está a la cabeza de 
la lista la más vieja, y la del final, la más reciente. Cuando hay una falla de página, se elimina la página 
que está a la cabeza de la lista y se agrega la nueva página al final. Cuando FIFO se aplica a una tienda, el 
producto eliminado podría ser cera para el bigote, pero también podría ser harina, sal o mantequilla. 
Cuando FIFO se aplica a computadoras, surge el mismo problema. Por esta razón, casi nunca se usa FIFO 
en su forma pura. 

4.4.4 F1 algoritmo de sustitución de páginas de segunda oportunidad 

Una modificación sencilla de FIFO que evita el problema de desalojar una página muy utilizada consiste 
en inspeccionar el bit R de la página más vieja. Si es O, sabremos que la página, además de ser vieja, no 
ha sido utilizada recientemente, así que la reemplazamos de inmediato. Si el bit R es 1, se apaga el bit, se 
coloca la página al final de la lista de páginas, y se actualiza su tiempo de carga como si acabara de ser 
traída a la memoria. Luego continúa la búsqueda. 

El fúncionamiento de este algoritmo, llamado de segunda oportunidad, se muestra en la Fig. 4- 
13. En la Fig. 4-13(a) vemos que se mantienen las páginas de la A a la H en una lista enlazada ordenadas 
según el momento en que se trajeron a la memoria. 

Supongamos que ocurre una falla de página en el tiempo 20. La página más antigua es A, que 
legó en el tiempo O, cuando se inició el proceso. Si A tiene el bit R apagado, es desalojada de la memoria, 
ya sea escribiéndose en el disco (si está sucia) o simplemente abandonándose (si está limpia). En cambio, 
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Página que se cargó primero 

Página que se cargó 
más recientemente 


(«) 


A se trata como págna 
recién cargada 


(b) 

Figura 4*13. Funcionamiento del algoritmo de segunda oportunidad, (a) Páginas ordenadas 
en orden FIFO. < b) Lista de páginas si ocurre una falla de página en el tiempo 20 y A tiene su 
bit R encendido. 


3 7 8 12 14 15 18 20 
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si el bit R está encendido, A se coloca al final de la lista y su "tiempo de carga" se ajusta al tiempo actual 
(20). También se apaga su bit R. La búsqueda de una página apropiada continúa con B. 

Lo que hace el algoritmo de segunda oportunidad es buscar una página vieja a la que no se, haya 
hecho referencia en el intervalo de reloj anterior. Si se ha hecho referencia a todas las páginas, este 
algoritmo pasa a ser FIFO puro. Específicamente, imaginemos que todas las páginas de la Fig. 4-13(a) 
tienen su bit R encendido. Una por una, el sistema operativo pasará' páginas al final de la lista, apagando 
el bit R cada vez que anexa una página al final de la lista. Tarde o temprano, regresará a la página A, que 
ahora tiene su bit R apagado. En este punto, A será desalojada. Así, el algoritmo siempre termina. 

4.4.5 El algoritmo de sustitución de páginas por reloj 

Aunque el algoritmo de segunda oportunidad es razonable, es innecesariamente eficiente porque 
constantemente cambia de lugar páginas dentro de su lista. Un enfoque mejor consiste en mantener todas 
las páginas en una lista circular con forma de reloj, como se muestra en la Fig. 4-14. Una manecilla apunta 
a la página más vieja. 

Cuando ocurre una falla de página, se inspecciona la página a la que apunta la manecilla. Si su bit 
R es O, se desaloja la página, se ins erta la nueva página en el reloj en su lugar, y la manecilla avanza una 
posición. Si R es 1, se pone en O y la manecilla se avanza a la siguiente página. Este proceso se repite 
hasta encontrar una página con R = 0. No resulta sorprendente que este algoritmo se llame de reloj. La 
única diferencia respecto al de segunda oportunidad es la implementación. 

4.4.6 El algoritmo de sustitución de páginas menos recientemente usadas (LRU) 

Una buena aproximación al algoritmo óptimo se basa en la observación de que las páginas que 
han usado mucho en las últimas instrucciones probablemente se usarán mucho en las siguientes. 
Por otro lado, las páginas que hace mucho no se usan probablemente seguirán sin usarse durante 
largo tiempo. Esta idea sugiere un algoritmo factible: cuando ocurra una falla de página, se desalojará 
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Cuando ocurre una falla de página, 
se inspecciona la página a la que apunta 
La manecilla La acción realizada depende 
del bit R: 

R * 0: Desalojar la página 


□ 


0 


R = i Apagar R y avanzar la manecilla 


□ 0 



Figura 4-14. Algoritmo de reemplazo de páginas por reloj. 


la página que haya estado más tiempo sin usarse. Esta estrategia se denomina paginación LRN (menos 
recientemente utilizada). 

Aunque LRU es factible en teoría, no es barato. Si queremos implementar LRU plenamente, 
necesitamos mantener una lista enlazada de todas las páginas que están en la memoria, con la página más 
recientemente utilizada al frente y la menos recientemente utilizada al final. El problema es que hay que 
actualizar la lista en cada referencia a la memoria. Encontrar una página en la lista, eli mi narla y luego 
pasarla al frente es una operación que consume mucho tiempo, incluso en hardware (suponiendo que 
pudiera construirse tal hardware). 

Sin embargo, hay otras formas de implementar LRU con hardware especial. Consideremos 
primero la forma más sencilla. Este método requiere equipar el hardware con un contador de 64 bits, C, 
que se incrementa automáticamente después de cada instrucción. Además, cada entrada de la tabla de 
páginas debe tener un campo con el tamaño suficiente para contener el contador. Después de cada 
referencia a la memoria, el valor actual de C se almacena en la entrada correspondiente a la página a la 
que se acaba de hacer referencia. Cuando ocurre una falla de página, el sistema operativo examina todos 
los contadores de la tabla de páginas hasta encontrar el más bajo. Esa página es la menos recientemente 
utilizada. 

Examinemos ahora un segundo algoritmo LRU en hardware. Para una máquina con n marcos de 
página, el hardware de LRU puede mantener una matriz de n x n bits, que inicialmente son cero. Cada vez 
que se hace referencia al marco de página k, el hardware pone primero en 1 todos los bits de la fila k, y 
luego pone en O todos los bits de la columna k. En un instante dado, la fila cuyo valor binario sea el más 
bajo, será la de la página menos recientemente utilizada; la fila cuyo valor sea el siguiente más bajo será la 
de la siguiente página menos recientemente utilizada, etc. El funciona mi ento de este algoritmo se muestra 
en la Fig. 4-15 para cuatro marcos de página y referencias a páginas en el orden 


0123210323 


Después de que se hace referencia a la página O tenemos la situación de la Fig. 4-15(a), y así 
sucesivamente. 
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Página Página Página Página Página 




Figura 4-15. LKU empleando una matriz. 


4.4.7 Simulación de LRU en software 

Aunque los dos algoritmos LRU anteriores son factibles en principio, pocas máquinas, y tal ninguna, 
cuentan con este hardware, así que no sirven de mucho al diseñador de sistemas operad que está creando 
un sistema para una máquina que no tiene este hardware. Se necesita solución que pueda implementarse 
en software. Una posibilidad es el algoritmo NFU (no utiliza frecuentemente), el cual requiere un 
contador en software asociado a cada página y que inicialmente vale 0. En cada interrupción del reloj, el 
sistema operativo examina todas las páginas que estañe memoria. Para cada página, el bit R, que es O o 1, 
se suma al contador. En efecto, los contados son un intento por contabilizar la frecuencia con que se hace 
referencia a cada página. Cuando ocurre una falla de página, se escoge para reemplazar la página que tiene 
el contador más bajo. 

El problema con NFU es que nunca olvida nada. Por ejemplo, en un compilador de múltiples 
pasadas, las páginas que se usaron mucho durante la pasada 1 podrían tener todavía una cuenta alta 
durante varias pasadas posteriores. De hecho, si sucede que la pasada 1 tiene el tiempo ejecución más 
largo de todas, las páginas que contienen el código de pasadas subsecuentes podrían tener siempre cuentas 
más bajas que las de la primera pasada. Por tanto, el sistema operativo desalojará páginas útiles en lugar 
de páginas que ya no se están usando. 

Por fortuna, una pequeña modificación de NFU hace que pueda simular LRU de forma 
satisfactoria. La modificación tiene dos partes. Primera, todos los contadores se desplazan a la derecha un 
bit antes de sumarles el bit R. Segunda, el bit R se suma al bit de la extrema izquierda al de la extrema 
derecha. \ 

En la Fig. 4-16 se ilustra el fúncionamiento del algoritmo modificado, llamado 
de maduración. Supongamos que después del primer tic del reloj los bits R de las páginas O a 5 tienen los 
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valores 1,0, 1,0, 1 y 1 respectivamente (la página O es 1, la página 1 es O, la página 2 es 1, etc.). Dicho 
de otro modo, entre el tic O y el tic 1 se hizo referencia a las páginas 0,2,4 y 5, así que sus bits R se 
pusieron en 1, mientras que los demás siguieron en 0. Después de que los seis contadores correspondientes 
se desplazan a la derecha y se les inserta el bit R por la izquierda, tienen los valores que se muestran en la 
Fig. 4-16(a). Las cuatro columnas restantes muestran los seis contadores después de los siguientes cuatro 
tics del reloj. 


Bits R 

de las páginas 0-5. 
fcdelreiojO 

Bits R 

da las páginas 0-5, 
be del rato) 1 

Bits R 

da las páginas 0-5. 
tic del reloj 2 

Bits R 

de las páginas 0-5. 
tic del reloj 3 

Bits R 

de las páginas 0-5. 
tic del reloj 4 

[ffffl 

l , l'l°M , l°l 

1 , I , I°I'M , I 
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l°|iM 0 Mo| 
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I 11000000 | 

I 11100000 | 

I 11110000 | 

¡ 01111000 | 






1¡ oooooooo | 

I 10000000 | 

I 11000000 | 

I 01100000 ] 

I 10110000 | 






2 ¡ 10000000 | 

I 01000000 | 

I 00100000 | 

I 00100000 | 

I 10001000 | 
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| oooooooo | 

[ '0000000 | 

I 01000000 | 

1 00100000 | 






«I '0000000 | 

I 11000000 | 

1 01100000 | 

I 10110000 ¡ 

1 01011000 | 






5| '0000000 | 

I 01000000 | 

I 10100000 | 

1 01010000 | 

1 00101000 ] 


(a) 0» (c) (d) (e) 

Figura 4-16. El algoritmo de maduración simula LRU en software. Se muestran seis pági¬ 
nas durante cinco tics del reloj. Los cinco lies se representan con las Figs. (a) a (e). 


Cuando ocurre una falla de página, se el im ina la página con el contador más bajo. Es evidente que 
una página a la que no se ha hecho referencia durante, digamos, cuatro tics del reloj tiene cuatro ceros a la 
izquierda en su contador, y por tanto tiene un valor más bajo que el contador de una página a la que no se 
ha hecho referencia durante tres tics del reloj. 

Este algoritmo difiere de LRU en dos aspectos. Consideremos las páginas 3 y 5 en la Fig. 4-16(e). 
A ninguna de las dos se ha hecho referencia durante dos tics del reloj; a las dos se hizo referencia en el tic 
anterior. Según LRU, si es preciso reemplazar una página, deberíamos escoger una de estas dos. El 
problema es que no sabemos cuál de ellas es a la que se hizo referencia por última vez en el intervalo entre 
el tic 1 y el 2. Al registrar sólo un bit por intervalo de tiempo, hemos perdido la capacidad para distinguir 
entre las referencias al principio del intervalo de reloj y aquellas que ocurren posteriormente. Lo único que 
podemos hacer es eliminar la página 3, porque la página 5 también tuvo una referencia dos tics antes, y la 
página 3 no. 

La segunda diferencia entre LRU y maduración es que en esta última los contadores tienen un 
número finito de bits, ocho en nuestro ejemplo. Supongamos que dos páginas tienen un valor de 
cero en el contador. Lo único que podemos hacer es escoger una de ellas al azar. En realidad, bien 
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puede ser que a una de ellas se haya hecho referencia por última vez hace nueve tics y que otra se haya 
hecho referencia por última vez hace 1000 tics. No tenemos forma de saber esto no obstante, en la práctica 
generalmente bastan ocho bits si un tic de reloj tiene alrededor de 20 Si no se ha hecho referencia a una 
página en 160 ms, probablemente no es muy importante. 

4.5 ASPECTOS DE DISEÑO DE LOS SISTEMAS CON PAGINACIÓN 

En las secciones anteriores hemos explicado cómo fúnciona la paginación y hemos presentado algunos de 
los algoritmos de reemplazo de páginas básicos. Sin embargo, no basta con conocer los aspectos 
mecánicos del fúncionamiento. Para diseñar un sistema, necesitamos saber mucho más si queremos lograr 
que fúncione bien. La diferencia es similar a la que existe entre saber cómo se mueven la torre, el caballo, 
el alfil y las demás piezas de ajedrez, y ser un buen jugador En las siguientes secciones examinaremos 
otros aspectos que los diseñadores de sistemas operad deben considerar detenidamente si quieren obtener 
un buen rendimiento de un sistema de paginación 

4.5.1 El modelo de conjunto de trabajo 

En la forma más pura de paginación, los procesos se inician con ninguna de sus páginas en la memoria. 
Tan pronto como la CPU trata de obtener la primera instrucción, detecta una falla página que hace que el 
sistema operativo traiga a la memoria la página que contiene dicha ins trucción. Por lo regular, pronto 
ocurren otras fallas de página al necesitarse variables globales y la pila. Después de un tiempo, el proceso 
tiene la mayor parte de las páginas que necesita y se dedica a ejecutarse con relativamente pocas fallas de 
página. Tal estrategia se denomina paginación por demanda porque las páginas se cargan sólo cuando se 
piden, no por adelantado. 

Desde luego, es fácil escribir un programa de prueba que lea sistemáticamente todas páginas de un 
espacio de direcciones grande, causando tantas fallas de página que no habrá suficiente memoria para 
contenerlas todas. Por fortuna, la mayor parte de los procesos no funcionan así; exhiben una localidad de 
referencia, lo que significa que durante cualquier fase de ejecución, el proceso sólo hace referencia a una 
fracción relativamente pequeña de sus páginas. Cada pasada de un compilador de múltiples pasadas, por 
ejemplo, sólo hace referencia a fracción de todas las páginas, que es diferente en cada pasada. 

El conjunto de páginas que un proceso está usando actualmente es su conjunto de trabajo 
(Denning, 1968a; Denning, 1980). Si todo el conjunto de trabajo está en la memoria, el proceso ejecutará 
sin causar muchas fallas hasta que pase a otra fase de su ejecución (p. ej., la siguiente pasada de un 
compilador). Si la memoria disponible es demasiado pequeña para contener todo conjunto de trabajo, el 
proceso causará muchas fallas de página y se ejecutará lentamente, ya que la ejecución de una instrucción 
normalmente toma unos cuantos nanosegundos, y la lectura; una página de disco suele tomar decenas de 
milisegundos. Si ejecuta sólo una o dos ins trucción cada 20 milisegundos, el proceso tardará muchísimo 
en terminar. Se dice que un programa q causa fallas de página repetidamente después de unas cuantas 
instrucciones se está "sacudiendo (en inglés, thrashing, que es el término que utilizaremos) (Denning, 
1968b). ’¡ 
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En un sistema de tiempo compartido, los procesos a menudo se transfieren al disco (esto es, todas 
sus páginas se eli mi nan de la memoria) para que otro proceso tenga oportunidad de usar la CPU. Surge la 
pregunta de qué hacer cuando se vuelve a traer un proceso a la memoria. Técnicamente, no hay que hacer 
nada. El proceso simplemente causará fallas de página hasta que haya cargado su conjunto de trabajo. El 
problema es que tener 20, 50 o incluso 100 fallas de página cada vez que se carga un proceso hace lento el 
funcionamiento y además desperdicia mucho tiempo de CPU, pues el sistema operativo requiere unos 
cuantos milisegundos de tiempo de CPU para procesar una falla de página. 

Por ello, muchos sistemas de paginación tratan de seguir la pista al conjunto de trabajo de cada 
proceso y se aseguran de que esté en la memoria antes de dejar que el proceso se ejecute. Este enfoque se 
denomina modelo de conjunto de trabajo (Denning, 1970) y está diseñado para reducir 
considerablemente la tasa de fallas de página. La carga de las páginas antes de dejar que los procesos se 
ejecuten también se denomina prepaginación. 

A fin de implementar el modelo de conjunto de trabajo, el sistema operativo tiene que saber cuáles 
páginas están en el conjunto de trabajo. Una forma de seguir la pista a esta información es usar el 
algoritmo de maduración que acabamos de explicar. Cualquier página que contenga un bit 1 entre los n 
bits de orden alto del contador se considera miembro del conjunto de trabajo. Si no se ha hecho referencia 
a una página en n tics de reloj consecutivos, se omite del conjunto de trabajo. El parámetro n se debe 
determinar experimentalmente para cada sistema, pero por lo regular el rendimiento del sistema no es muy 
sensible al valor exacto. 

La información relativa al conjunto de trabajo puede servir para mejorar el rendimiento del 
algoritmo del reloj. Normalmente, cuando la manecilla apunta a una página cuyo bit R es O, esa página se 
desaloja. La mejora consiste en verificar si esa página forma parte del conjunto de trabajo del proceso en 
curso. Si lo es, se le perdona la vida. Este algoritmo se conoce como wsclock. 

4.5.2 Políticas de asignación local vs. global 

En las secciones anteriores hemos descrito varios algoritmos para escoger la página que será sustituida 
cuando ocurra una falla de página. Un problema importante asociado a esta decisión (que tuvimos cuidado 
de no mencionar hasta ahora) es la forma como debe repartirse la memoria entre los procesos ejecutables 
competidores. 

Dé una mirada a la Fig. 4-17(a). En esta figura, tres procesos. A, B y C, constituyen el conjunto de 
los procesos ejecutables. Supongamos que A causa una falla de página. ¿El algoritmo de sustitución de 
páginas deberá tratar de encontrar la página menos recientemente utilizada considerando sólo las seis 
páginas que actualmente están asignadas a A o deberá considerar todas las páginas que están en la 
memoria? Si se examinan sólo las páginas de A, la página con el valor de edad más bajo será A5, y 
tendremos la situación de la Fig. 4-17(b). 

Por otro lado, si se desaloja la página con el valor de edad más bajo sin tener en cuenta a quién 
pertenece, se escogerá la página B3 y tendremos la situación de la Fig. 4-17(c). El algoritmo de la I Fig. 4- 
17(b) es un algoritmo de reemplazo de páginas local, en tanto que el de la Fig. 4-17(c) es global. 
Los algoritmos locales corresponden efectivamente a asignar a cada proceso una 
fracción fija de la memoria. Los algoritmos globales reparten dinámicamente marcos de página entre los 
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Figura 4-17. Reemplazo de páginas local vs. global, (a) Configuración original, (b) Reem¬ 
plazo de páginas local, (c) Reemplazo de páginas global. 


procesos ejecutables. Por tanto, el número de marcos de página asignados a cada proceso varía con el 
tiempo. 

En general, los algoritmos globales funcionan mejor, sobre todo cuando el tamaño del conjunto de 
trabajo puede variar durante la vida de un proceso. Si se emplea un algoritmo local y el conjunto de 
trabajo crece, habrá thrashing, incluso si hay muchos marcos de página libres. Si el conjunto de trabajo se 
reduce, los algoritmos locales desperdician memoria. Si se emplea un algoritmo global, el sistema debe 
decidir continuamente cuántos marcos de página habrá de asignar a cada proceso. Una forma de vigilar el 
tamaño del conjunto de trabajo es examinar los bits de maduración, pero este enfoque no necesariamente 
evita el thrashing. El tamaño del conjunto de trabajo puede cambiar en microsegundos, en tanto que los 
bits de maduración son una medida, burda que abarca varios tics del reloj. 

Otro enfoque consiste en tener un algoritmo para asignar marcos de página a los procesos. Una 
posibilidad es determinar periódicamente el número de procesos en ejecución y asignar a cada uno una 
porción equitativa. Así, con 475 marcos de página disponibles (es decir, no ocupar dos por el sistema 
operativo) y 10 procesos, le tocarían 47 marcos a cada proceso. Los cinco restantes constituirían una 
reserva que se usaría en caso de ocurrir fallas de página. 

Aunque este método parece justo, no tiene mucha lógica dar porciones iguales de la memoria un 
proceso de 10K y a uno de 300K. En vez de ello, se pueden asignar las páginas en proporción al tamaño 
total de cada proceso, de modo que un proceso de 300K reciba 30 veces más memoria que uno de 10K. 
Tal vez sea prudente dar a cada proceso alguna cantidad mí nim a para que pueda 
ejecutarse por más pequeño que sea. En algunas máquinas, por ejemplo, una sola instrucción podría 
requerir hasta seis páginas porque la in s trucción misma, el operando de origen y 
el operando de destino podrían estar cada uno exactamente en la frontera entre dos páginas, con una parte 
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en cada lado. Con una asignación de sólo cinco páginas, un programa que incluyera una instrucción 
semejante no podría ejecutarse. 

Ni el método de reparto equitativo ni el de reparto proporcional resuelven directamente el 
problema del thrashing. Una forma más directa de controlarlo consiste en usar el algoritmo de asignación 
de frecuencia de fallas de página, o PFF. En una clase amplia de algoritmos de sustitución de páginas, 
incluido LRU, se sabe que la tasa de fallas disminuye al asignarse más páginas, como ya explicamos. Esta 
propiedad se ilustra en la Fig. 4-18. 



Rgura 4-18. La tasa de fallas de página en función del número de marcos de página asignados. 

La línea punteada A corresponde a una tasa de fallas de página inaceptablemente alta, así que se 
asignan más marcos de página al proceso que las está generando a fin de reducir dicha tasa. La línea 
punteada B corresponde a una tasa de fallas de página tan baja que podemos concluir que el proceso tiene 
demasiada memoria. En este caso, podemos quitarle marcos de página. Así, PFF trata de mantener la tasa 
de paginación dentro de límites aceptables. 

Si el algoritmo descubre que hay tantos procesos en la memoria que no es posible mantenerlos a 
todos por debajo de A, se eliminará algún proceso de la memoria y sus marcos de página se repartirán 
entre los procesos restantes o se colocarán en una reserva de páginas disponibles que podrán usarse en 
fallas de página subsecuentes. La decisión de sacar a un proceso de la memoria es una forma de control de 
carga. Esto pone de manifiesto que, incluso con paginación, todavía es necesario el intercambio, sólo que 
ahora se usa para reducir la demanda potencial de memoria, no para recuperar sus bloques y usarlos de 
inmediato. 

4,5.3 Tamaño de página 

En muchos casos, el tamaño de página es un parámetro que el sistema operativo puede escoger. Incluso si 
el hardware se diseñó con páginas de, por ejemplo, 512 bytes, el sistema operativo fácilmente puede 
considerar las páginas O y 1, 2 y 3, 4 y 5,etc., como páginas de 1K asignando siempre dos marcos de 
página de 512 bytes consecutivos a ellas. 

La determinación del tamaño de página óptimo requiere balancear varios factores opuestos. Por 
principio, un segmento de texto, datos o pila escogido al azar no llena un número entero de 
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páginas. En promedio, la mitad de la página final estará vacía. El espacio extra de esa página se 
desperdicia, y este desperdicio se denomina fragmentación intema. Con n segmentos en memoria y un 
tamaño de página de p bytes, se desperdiciarán np/2 bytes por fragmentación intema. Este razonamiento 
es un argumento a favor de las páginas pequeñas. 

Otro argumento a favor de un tamaño de página pequeño se hace evidente si pensamos en un 
programa que consiste en ocho fases secuenciales de 4K cada una. Con un tamaño de página 32K, habría 
que asignar al programa 32K todo el tiempo. Con un tamaño de página de 16K programa sólo necesitaría 
16K. Con un tamaño de página de 4K o menor, el programa se requeriría 4K en un momento dado. En 
general, un tamaño de página grande hará que haya proporción mayor de programa no utilizado en la 
memoria que si se usan páginas pequeñas. 

Por otro lado, el empleo de páginas pequeñas implica que los programas necesitarán muchas 
páginas, y la tabla de páginas será grande. Un programa de 32K sólo necesita cuatro páginas 8K, pero 64 
páginas de 512 bytes. Las transferencias entre la memoria y el disco generalmente son de páginas 
completas, y la mayor parte del tiempo se invierte en la búsqueda y el retardo rotacional, de modo que la 
transferencia de una página pequeña toma casi tanto tiempo como en una página grande. Podrían 
requerirse 64 x 15 ms para cargar 64 páginas de 512 bytes, pero sólo 4 x 25 ms para cargar cuatro páginas 
de 8K. 

En algunas máquinas, la tabla de páginas debe cargarse en registros de hardware cada que la CPU 
conmuta de un proceso a otro. En estas máquinas, tener un tamaño de página pequeña implica que el 
tiempo requerido para cargar los registros de páginas aumenta conforme el tamaño de página disminuye. 
Además, el espacio ocupado por la tabla de páginas aumenta al disminuir el tamaño de página. 

Este último punto puede analizarse matemáticamente. Sea s el tamaño de proceso promedio en 
bytes y p el tamaño de página en bytes. Además, suponga que cada entrada de página requiere bytes. El 
número apropiado de páginas requeridas por proceso es entonces s/p, que ocupan p bytes en la tabla de 
páginas. La memoria desperdiciada en la última página del proceso debido a la fragmentación intema es 
p/2. Por tanto, el gasto extra total debido a la tabla de páginas y a la pérdida por fragmentación intema está 
dada por 


gasto extra = selp + p/2 

El primer término (tamaño de la tabla de páginas) es grande cuando el tamaño de página pequeño. 
El segundo término (fragmentación intema) es grande cuando el tamaño de página es grande. El tamaño 
óptimo debe estar en algún punto intermedio. Si obtenemos la primera derivada respecto a p y la 
igualamos a cero, tenemos la ecuación 


-selp2 +1/2=0 

De esta ecuación podemos deducir una fórmula que da el tamaño de página óptimo (considerando sólo la 
memoria desperdiciada por fragmentación y el tamaño de la tabla de páginas). El resultado 


p = A 2se 
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Para s = 128K y e = 8 bytes por entrada de tabla de páginas, el tamaño de página óptimo es de 1448 bytes. 
En la práctica se usaría 1K o 2K, dependiendo de los demás factores (p. ej., rapidez del disco). La mayor 
parte de las computadoras comerciales emplean tamaños de página que van desde 512 bytes hasta 64K. 

4.5.4 Interfaz de memoria virtual 

Hasta ahora, hemos supuesto que la memoria virtual es transparente para los procesos y los 
programadores. Esto es, todo lo que ellos ven es un espacio de direcciones virtual grande en una 
computadora con una memoria física (más) pequeña. En muchos sistemas, esto es cierto, pero en algunos 
sistemas avanzados los programadores tienen cierto control sobre el mapa de memoria y lo pueden utilizar 
de formas no tradicionales. En esta sección veremos brevemente algunas de ellas. 

Una razón para dar a los programadores control sobre su mapa de memoria es permitir que dos o 
más procesos compartan la misma memoria. Si los programadores pueden nombrar regiones de su 
memoria, un proceso puede darle a otro el nombre de una región de memoria para que pueda incluirla en 
su mapa. Cuando dos (o más) procesos comparten las mismas páginas, se hace posible la compartición de 
alto ancho de banda: un proceso escribe en la memoria compartida y el otro la lee. 

La compartición de páginas también puede servir para implementar un sistema de transferencia de 
páginas de alto rendimiento. Normalmente, cuando se transfieren mensajes, los datos se copian de un 
espacio de direcciones a otro, pagando un precio considerable. Si los procesos pueden controlar su mapa 
de páginas, se puede transferir un mensaje haciendo que el proceso transmisor excluya de su mapa la 
página o páginas que contienen el mensaje, y que el proceso receptor las incluya en su mapa. Aquí sólo 
tendrían que copiarse los nombres de página, no todos los datos. 

Otra técnica de administración avanzada de memoria es la memoria compartida distribuida 
(Feeley et al., 1995; Li y Hudak, 1989; Zekauskas et al., 1994). De lo que se trata aquí es de permitir que 
múltiples procesos en una red compartan un conjunto de páginas, posiblemente, aunque no 
necesariamente, como un solo espacio de direcciones lineal compartido. Cuando un proceso hace 
referencia a una página que actualmente no está en su mapa, genera una falla de página. El manejador de 
fallas de página, que puede estar en el kemel o en el espacio de usuario, localiza entonces la máquina que 
tiene la página y le envía un mensaje pidiéndole que la excluya de su mapa y la envíe por la red. Cuando 
llega la página, se incluye en el mapa y se reinicia la instrucción que falló. 

4.6 SEGMENTACIÓN 

La memoria virtual de la que hemos hablado hasta ahora es unidimensional porque las 
direcciones virtuales van desde O hasta alguna dirección máxima, una dirección tras otra. Para muchos 
problemas, tener dos o más espacios de direcciones virtuales independientes puede ser mucho mejor 
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que tener sólo uno. Por ejemplo, un compilador tiene muchas tablas que se construyen conforme procede 
la compilación, y que pueden incluir 

1. El texto fuente que se está guardando para el listado impreso (en sistemas por lotes). 

2. La tabla de símbolos, que contiene los nombres y los atributos de las variables. 

3. La tabla que contiene todas las constantes enteras y de punto flotante empleadas. 

4. El árbol de análisis sintáctico, que condene el árbol de análisis sintáctico del programa. 

5. La pila empleada para llamadas a procedimientos dentro del compilador. 

Las primeras cuatro tablas crecen continuamente conforme avanza la compilación. La última crece y se 
encoge de forma impredecible durante la compilación. En una memoria unidimensional, habría que 
asignar a estas cinco tablas trozos contiguos del espacio de direcciones virtual, como en la Fig.4-19. 


Espacio Pe direcciones virtual 


Espacio de 
direcciones asignado 
al árbol de análisis 
sintáctico 



Árbol de análisis 
sintáctico 



Tarto fuente | 

r 

Tablada 

símbolos 


[ Ubre 

i Espacio ocupado actualmente 
I por el árbol de análisis sintáctico 


La tabla de símbolos chocó 
contra la tabla de texto fuente 


Figura 4-19. En un espacio de direcciones unidimensional con tablas crecientes, una tabla 
podría chocar contra otra. 


Consideremos lo que sucede si un programa tiene un número excepcionalmente grande de 
variables. El trozo del espacio de direcciones asignado a la tabla de símbolos podría llenarse, pero podría 
haber espacio de sobra para otras tablas. Desde luego, el compilador podría limitarse a exhibir un mensaje 
diciendo que la compilación no puede continuar debido a un exceso de variables, pero esto no parece justo 
si hay espacio desocupado en las otras tablas. 

Otra posibilidad es hacerla de Robín Hood, tomando espacio de las tablas que tienen mucho 
espacio y dándolo a las que tienen poco. Es posible efectuar estos movimientos, pero sería 
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análogo a administrar las propias superposiciones: una molestia en el mejor de los casos y una gran 
cantidad de trabajo tedioso y fútil en el peor. 

Lo que realmente se necesita es una forma de liberar al programador de la tarea de administrar las 
tablas en expansión y contracción, del mismo modo como la memoria virtual elimina la preocupación de 
tener que organizar el programa en superposiciones. 

Una solución directa y en extremo general consiste en proveer a la máquina con muchos espacios 
de direcciones completamente independientes, llamados segmentos. Cada segmento consiste en una 
secuencia lineal de direcciones, desde O hasta algún máximo. La longitud de cada segmento puede ser 
cualquiera desde O hasta el máximo permitido. Los diferentes segmentos pueden, y suelen, tener 
diferentes longitudes. Es más, la longitud de los segmentos puede cambiar durante la ejecución. La 
longitud de un segmento de pila puede aumentarse cada vez que algo se empila y reducirse cada vez que 
algo se desempila. 

Puesto que cada segmento constituye un espacio de direcciones aparte, los distintos segmentos 
pueden crecer o encogerse de forma independiente, sin afectarse entre sí. Si una pila de cierto segmento 
necesita más espacio de direcciones para crecer, se le puede conceder, porque no hay nada más en su 
espacio de direcciones con lo que pueda chocar. Desde luego, podría llenarse un segmento, pero los 
segmentos suelen ser muy grandes, así que esta ocurrencia es poco común. Para especificar una dirección 
en esta memoria segmentada o bidimensional, el programa debe proporcionar una dirección de dos partes: 
un número de segmento y una dirección dentro de ese segmento. En la Fig. 4-20 se ilustra una memoria 
segmentada empleada para las tablas de compilador que vimos antes. 



Figura 4-20. Una memoria segmentada permite a cada tabla crecer o encogerse con indepen¬ 
dencia de las demás tablas. 


Subrayamos que un segmento es una entidad lógica, de la cual el programador está consciente y 
que utiliza como entidad lógica. Un segmento podría contener un procedimiento, un arreglo, 
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una pila o una colección de variables escalares, pero por lo regular no contiene una mezcla diferentes 
cosas. 

Las memorias segmentadas tienen otras ventajas además de simplificar el manejo de estructuras 
de datos que están creciendo o encogiéndose. Si cada procedimiento ocupa un segmento aparte, con la 
dirección O como dirección inicial, se simplifica considerablemente la vinculación de procedimientos 
compilados por separado. Una vez que se han compilado y vinculado todos 1 procedimientos que 
constituyen un programa, una llamada al procedimiento del segmento n usa la dirección de dos partes (n, 
0) para direccionar la palabra O (el punto de entrada). 

Si el procedimiento que está en el segmento n se modifica y recompila subsecuentemente, i hay 
necesidad de alterar ningún otro procedimiento (porque no se modificó ninguna dirección i inicio), incluso 
si la nueva versión es más grande que la anterior. Con una memoria unidimensional los procedimientos se 
empacan uno junto a otro, sin espacio de direcciones entre ellos. En consecuencia, la modificación del 
tamaño de un procedimiento puede afectar la dirección de inicio i otros procedimientos que no tienen 
relación con él. Esto, a su vez, requiere la modificación de todos los procedimientos que invocan a 
cualquiera de los procedimientos que se moviere incorporando sus nuevas direcciones de inicio. Si un 
programa contiene cientos de procedimiento este proceso puede ser costoso. 

La segmentación también facilita compartir procedimientos o datos entre varios procese Un 
ejemplo común es la biblioteca compartida. Las estaciones de trabajo modernas que ejecute sistemas de 
ventanas avanzados suelen tener bibliotecas de gráficos extremadamente grandes compiladas en casi todos 
sus programas. En un sistema segmentado, la biblioteca de gráficos puede colocar en un segmento 
compartido por múltiples procesos, eliminando la necesidad \ tenerla en el espacio de direcciones de cada 
proceso. Si bien también es posible tener bibliotecas compartidas en los sistemas con paginación pura, 
resulta mucho más complicado. De hecho esos sistemas lo logran simulando segmentación. 

Dado que cada segmento constituye una entidad lógica de la cual el programador está consciente, 
como un procedimiento, un arreglo o una pila, los diferentes segmentos pueden ten diferentes tipos de 
protección. Un segmento de procedimientos se puede especificar como so de ejecución, prohibiendo los 
intentos por leerlo o escribir en él. Un arreglo de punto flotante puede especificar como de 
lectura/escritura pero no de ejecución, y los intentos por saltar a serán atrapados. Semejante protección es 
útil para detectar errores de programación. 

Conviene entender por qué la protección tiene sentido en una memoria segmentada pero i en una 
memoria paginada unidimensional. En una memoria segmentada el usuario sabe qué hay (cada segmento. 
Normalmente, un segmento no contendría un procedimiento y una pila, p ejemplo, sino una cosa o la otra. 
Puesto que cada segmento contiene sólo una clase de objetos, segmento puede tener la protección 
apropiada para ese tipo en particular. La paginación y la segmentación se comparan en la Fig. 4-21. 

El contenido de una página es, en cierto sentido, accidental. El programador no está consciente 
siquiera del hecho de que está ocurriendo la paginación. Aunque sería posible colocar unos 
cuantos bits en cada entrada de la tabla de páginas para especificar el acceso permitido, 
para aprovechar esta capacidad el programador tendría que saber en dónde están las fronteras 
de página dentro de su espacio de direcciones. Ésta es precisamente la clase de administración que 
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Figura 4-21. Comparación de paginación y segmentación. 

se buscaba eliminar al inventar la paginación. Como el usuario de una memoria segmentada tiene la 
ilusión de que todos los segmentos están en la memoria principal todo el tiempo —es decir, puede 
direccionarlos como si así fuera— puede proteger cada segmento individualmente, sin tener que 
preocuparse por la administración que implica superponerlos. 

4.6.1 Implementación de la segmentación pura 

La implementación de la segmentación difiere de la de la paginación en un aspecto esencial: el tamaño de 
las páginas es fijo pero el de los segmentos no. En la Fig. 4-22(a) se muestra un ejemplo de memoria física 
que inicialmente contiene cinco segmentos. Consideremos ahora qué sucede si se desaloja el segmento 1 y 
se coloca en su lugar el segmento 7, que es más pequeño. Llegamos a la configuración de memoria de la 
Fig. 4-22(b). Entre el segmento 7 y el segmento 2 hay un área desocupada, es decir, un agujero. Luego el 
segmento 4 es sustituido por el segmento 5, como en la Fig. 4-22(c), y el segmento 3 es reemplazado por 
el segmento 6, como en la Fig. 4-22(d). Después de cierto tiempo de ejecución del sistema, la memoria 
estará dividida en varios trozos, unos con segmentos y otros con agujeros. Este fenómeno, llamado 
cuadriculación o fragmentación externa, desperdicia memoria en los agujeros. El remedio es la 
compactación, como se muestra en la Fig. 4-22(e). 
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Figura 4-2 2. (a)-(d) Desarrollo de la cuadriculación, (c) Eliminación de la cuadriculación por compactaos 
4.6.2 Segmentación con paginación: MULTICS 

Si los segmentos son grandes, puede ser problemático, o incluso imposible, mantenerlos completos en la 
memoria principal. Esto nos lleva a la idea de paginarlos, de modo que sólo se consérvenlas páginas que 
realmente se necesitan. Varios sistemas importantes han manejado segmentos paginados. En esta sección 
describiremos el primero: MULTICS. En la siguiente veremos uno más reciente: Pentium de Intel. 

MULTÍCS se ejecutaba en las maquinas Honeywell 6000 y sus descendientes y proporcionaba a 
cada programa una memoria virtual de hasta 218 segmentos (más de 250 000), cada uno de los '• cuales 
podía tener una longitud de hasta 65 536 palabras (de 36 bits). Para implementar esto, los diseñadores de 
MULTICS decidieron tratar cada segmento como una memoria virtual y paginarlo, combinando las 
ventajas de la paginación (tamaño de página uniforme y no tener que mantener todo el segmento en la 
memoria si sólo se está usando una parte) con las de la segmentación (facilidad de programación, 
modularidad, protección y compartición). 

Cada programa MULTICS tiene una tabla de segmentos, con un descriptor por segmento. Puesto 
que puede haber más de un cuarto de millón de entradas en la tabla, la tabla de segmentos es en sí un 
segmento y se pagina. Un descriptor de segmento contiene una indicación de si el segmento está en la 
memoria principal o no. Si cualquier parte del segmento está en la memoria, se considera que el segmento 
está en la memoria, y su tabla de páginas estará en la memoria. Si el segmento está en la memoria, su 
descriptor contiene un apuntador de 18 bits a su tabla de páginas | [véase la Fig. 4-23(a)]. Dado que las 
direcciones físicas tienen 24 bits y las páginas están alineadas según fronteras de 64 bytes (lo que implica 
que los seis bits de orden bajo de las direcciones de página son 000000), sólo se requieren 18 bits en el 
descriptor para almacenar una dirección de tabla de páginas. El descriptor también contiene el tamaño del 
segmento, los bits de protección y 
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unas cuantas cosas más. La Fig. 4-23(b) ilustra un descriptor de segmento MULTICS. La dirección del 
segmento en la memoria secundaria no está en el descriptor de segmento sino en otra tabla utilizada por el 
manejador de fallas de segmento. 



Tabla de páginas 
pata el segmento t 



(b) 

Figura 4-23. I.a memoria virtual MULTICS. (a) El segmento de descriptores apunta a las 
tablas de páginas, (b) Un descriptor de segmento. Los números son longitudes de campo. 


Cada segmento es un espacio de direcciones virtual ordinario y se pagina del mismo modo que la 
memoria paginada no segmentada que se describió en una sección anterior de este capítulo. El tamaño de 
página normal es de 1024 palabras (aunque unos cuantos segmentos pequeños que utiliza MULTICS 
mismo no están paginados o se paginan en unidades de 64 palabras a fin de ahorrar memoria física). 
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Una dirección en MULTICS consta de dos partes: el segmento y la dirección dentro del segmento. 
La dirección dentro del segmento se subdivide en un número de página y una palabra dentro de la página, 
como se muestra en la Fig. 4-24. Cuando ocurre una referencia a la memoria, se lleva a cabo el siguiente 
algoritmo. 

1. Se usa el número de segmento para encontrar el descriptor de segmento. 

2. Se verifica si la tabla de páginas del segmento está en la memoria. Si es así, se le localiza; si no, ocurre 
una falla de segmento. Si hay una violación de la protección, ocurre una falla (trampa). 

3. Se examina la entrada de tabla de páginas que corresponde a la página virtual solicitada. Si la página no 
está en la memoria, ocurre una falla de página; si está en la memoria, se extrae de la entrada de la tabla de 
páginas la dirección de principio de la página en la memoria principal. 

4. Se suma la distancia al origen de la página para obtener la dirección en la memoria principal donde se 
encuentra la palabra. 

5. Finalmente se efectúa la lectura o el almacenamiento. 


Dirección dentro 
del segmento 


Número de segmento 


Número de 

Desplazamiento 

página 

dentro de la página 

6 

10 


Figura 4-24. Dirección virtual MULTICS de 34 bits. 


Este proceso se ilustra en la Fig. 4-25. Por sencillez, se omite el hecho de que el segmento de 
descriptores mismo también está paginado. Lo que realmente sucede es que se usa un registro (el registro 
base de descriptores) para localizar la tabla de páginas del segmento de descriptores, la cual, a su vez, 
apunta a las páginas del segmento de descriptores. Una vez encontrado el descriptor del segmento 
requerido, el direccionamiento procede tal como se muestra en la Fig. 4-25. 

Como sin duda el lector ya adivinó, si el sistema operativo ejecutara el algoritmo anterior en cada 
instrucción, los programas no se ejecutarían con mucha rapidez. En realidad, el hardware de MULTICS 
contiene un TLB de alta velocidad de 16 palabras que puede buscar una clave dada en paralelo en todas 
sus entradas. Este TLB se ilustra en la Fig. 4-26. Cuando se presenta una dirección a la computadora, lo 
primero que hace el hardware de direccionamiento es ver si la dirección virtual está en el TLB. Si es así, 
obtiene el número de marco de página directamente del TLB y forma la dirección real de la palabra 
referida sin tener que examinar el segmento de descriptores ni la tabla de páginas. 

Las direcciones de las 16 páginas a las que se hizo referencia más recientemente se mantienen en 
el TLB. Los programas cuyo conjunto de trabajo es menor que el tamaño del TLB alcanzan un equilibrio 
con todo el conjunto de trabajo en el TLB y por tanto se ejecutan de forma muy 
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Figura 4-26. Versión simplificada del TLB de MULTICS. La existencia de dos tamaños de 
página hace que el TLB real sea más complicado. 


eficiente. Si la página no está en el TLB, se hace referencia a las tablas de descriptores y de páginas para 
encontrar la dirección del marco de página, y el TLB se actualiza de modo que: incluya esta página, 
desalojando la página menos recientemente utilizada. El campo de edad indica I cuál entrada es la que se 
usó menos recientemente. La razón por la que se usa un TLB es poder | comparar el número de segmento 
y el número de página de todas las entradas en paralelo. 
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4.6.3 Segmentación con paginación: El Pentium de Intel 

En muchos sentidos, la memoria virtual del Pentium (y Pentium Pro) se parece a la de MULTIC incluida 
la presencia tanto de segmentación como de paginación. Mientras que MULTICS tiene 256K segmentos 
independientes, cada uno con hasta 64K palabras de 36 bits, el Pentium tiene 16 segmentos 
independientes, cada uno con hasta mil millones de palabras de 32 bits. Aunque hi menos segmentos, el 
tamaño tan grande de los segmentos es mucho más importante, ya que pocos programas necesitan más de 
1000 segmentos, pero muchos programas requieren segmentos con capacidad de megabytes. 

El corazón de la memoria virtual Pentium consiste en dos tablas, la LDT (tabla de descriptor 
local) y la GDT (tabla de descriptores global). Cada programa tiene su propia LDT, pero sol hay una 
GDT, compartida por todos los programas de la computadora. La LDT describe k segmentos que son 
locales para cada programa, incluidos su código, datos, pila, etc., en tanto que la GDT describe los 
segmentos del sistema, incluido el sistema operativo mismo. 

Para acceder a un segmento, lo primero que hace un programa Pentium es cargar un selecto para 
ese segmento en uno de los seis registros de segmento de la máquina. Durante la ejecución el registro CS 
contiene el selector para el segmento de código y el registro DS contiene el selecto para el segmento de 
datos. Los otros registros de segmento son menos importantes. Cada selector es un número de 16 bits, 
como se muestra en la Fig. 4-27. 


Bits 13 _ 1 2 

índice 

1 -rV 

0 = GDT/1 = LDT Nivel de privilegio (0-3) 


Figura 4-27. Un selector Pentium. 


Uno de los bits selectores indica si el segmento es local o global (es decir, si está en la LDT o en 
la GDT). Trece bits más especifican el número de entrada en la LDT o la GDT, de modo que estas tablas 
están restringidas a contener cada una 8K descriptores de segmento. Los otros dos bits tienen que ver con 
la protección, y se describirán posteriormente. El descriptor O está prohibido; puede cargarse sin peligro 
en un registro de segmento para indicar que ese registro no esta disponible actualmente, pero causa una 
trampa si se usa. 

En el momento en que un selector se carga en un registro de segmento, el descriptor 
correspondiente se trae de la LDT o GDT y se almacena en registros de microprograma, a fin de poder 
acceder a él rápidamente. Un descriptor consiste en ocho bytes, que incluyen la dirección base del 
segmento, el tamaño y otra información, como se ilustra en la Fig. 4-28. 

El formato del selector se escogió ingeniosamente de modo que facilitara la localización del 
descriptor. Primero se selecciona ya sea la LDT o la GDT, con base en el bit 2 del selector. Luego se copia 
el selector en un registro temporal intemo y se ponen en cero los tres bits de orden bajo Por último, se le 
suma la dirección de la tabla LDT o GDT, para dar un apuntador directo al 
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Figura 4-28. Descriptor de segmento de código Pentium. Los de segmentos de datos son un poco diferentes. 


descriptor. Por ejemplo, el selector 72 se refiere a la entrada 9 de la GDT, que se encuentra en la dirección 
GDT + 72. 

Sigamos uno a uno los pasos mediante los cuales un par (selector, distancia) se convierte en una 
dirección física. Tan pronto como el microprograma sabe cuál registro de segmento se está usando, puede 
encontrar el descriptor completo que corresponde a ese selector en sus registros internos. Si el segmento 
no existe (selector 0), o sus páginas no están actualmente en la memoria, ocurre una trampa. 

Luego se verifica si la distancia rebasa el final del segmento, en cuyo caso también ocurre una 
trampa. Lógicamente, debería haber un campo de 32 bits en el descriptor para indicar el tamaño del 
segmento, pero sólo hay 20 bits disponibles, así que se emplea un esquema distinto. Si el campo Gbit 
(granularidad) es O, el campo Límite es el tamaño exacto del segmento, hasta 1 MB; si es 1, el campo 
Límite da el tamaño de segmento en páginas en lugar de bytes. El tamaño de página de Pentium está fijo 
en 4K bytes, así que bastan 20 bits para segmentos de hasta 232 bytes. 

Suponiendo que el segmento está en la memoria y que la distancia está dentro del intervalo, el 
Pentium suma entonces el campo Base de 32 bits del descriptor a la distancia para formar lo que se 
deno mi na dirección lineal, como se muestra en la Fig. 4-29. El campo Base se divide en tres I partes que 
se dispersan por el descriptor para mantener la compatibilidad con el 286, en el cual 1: Base sólo tiene 24 
bits. En efecto, el campo Base permite que cada segmento comience en un y lugar arbitrario dentro del 
espacio de direcciones lineal de 32 bits. 

Si se inhabilita la paginación (con un bit de un registro de control global), la dirección lineal se 
Interpreta como la dirección física y se envía a la memoria para la lectura o escritura. Así, con la 
paginación inhabilitada, tenemos un esquema de segmentación puro, con la dirección base de rada 
segmento dada en su descriptor. Por cierto, se permite que los segmentos se traslapen, probablemente 
porque implicaría demasiado trabajo y pérdida de tiempo verificar que todos sean mutuamente exclusivos. 

Por otro lado, si está habilitada la paginación, la dirección lineal se interpreta como dirección 1 y 
se transforma en la dirección física usando tablas de páginas, más o menos como en «os ejemplos 
anteriores. La única complicación real es que con una dirección virtual de 32 
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Figura 4-29. Conversión de un par (selector, desplazamiento) en una dirección lineal. 


bits y páginas de 4K, un segmento podría contener un millón de páginas, así que se usa transformación de 
dos niveles para reducir el tamaño de las tablas de páginas cuando los segmentos son pequeños. 

Cada programa en ejecución tiene un directorio de páginas que consiste en 1024 entradas de 32 bits cada 
una. Este directorio está en una dirección a la que apunta un registro global. Cada entrada de este 
directorio apunta a una tabla de páginas que también contiene 1024 entradas de 32 bits.'.entradas de la 
tabla de páginas apuntan a marcos de páginas. El esquema se muestra en la Fig. 4-30 
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Directorio de páginas Tabla de páginas Marco de página 



Figura 4-30. Transformación de una dirección lineal en una dirección física. 


En la Fig. 4-30(a) vemos una dirección lineal dividida en tres campos, Dir, Página y DiSK campo 
Dir sirve como índice del directorio de páginas para encontrar un apuntador a la tabhj páginas apropiada. 
Luego se usa el campo Página como índice de la tabla de páginas para encontrar 
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la dirección física del marco de página. Por último, se suma Dist a la dirección de marco de página para 
obtener la dirección física del byte o palabra requerido. 

Las entradas de la tabla de páginas tienen 32 bits cada una, 20 de los cuales contienen un número 
de marco de página. Los bits restantes contienen bits de acceso y sucios, encendidos por el hardware para 
beneficio del sistema operativo, bits de protección y otros bits de utilería. 

Cada tabla de páginas tiene entradas para 1024 marcos de página de 4K, así que una sola tabla de 
páginas maneja 4 megabytes de memoria. Un segmento de menos de 4M tendrá un directorio de páginas 
con una sola entrada, un apuntador a su única tabla de páginas. De este modo, el gasto extra para los 
segmentos cortos es de sólo dos páginas, en lugar del millón de páginas que se requerirían en una tabla de 
páginas de un solo nivel. 

A fin de evitar hacer referencias repetidas a la memoria, el Pentium, al igual que MULTICS, tiene 
un pequeño TLB que transforma directamente las combinaciones Dir-Página más recientemente utilizadas 
en la dirección física del marco de página. Sólo si la combinación actual no está presente en el TLB se 
aplica el mecanismo de la Fig. 4-30 y se actualiza el TLB. 

Si pensamos un poco veremos que, si se usa paginación, realmente no tiene caso disponer de un 
campo Base distinto de cero en el descriptor. Todo lo que Base hace es indicar una distancia pequeña para 
usar una entrada en medio del directorio de páginas, en lugar de al principio. La verdadera razón para 
incluir Base es permitir la segmentación pura (no paginada), y por compatibilidad con el 286, que siempre 
tiene la paginación inhabilitada (es decir, el 286 tiene sólo segmentación pura, sin paginación). 

También vale la pena señalar que si alguna aplicación no necesita segmentación y está satisfecha 
con un solo espacio de direcciones de 32 bits paginado, es posible emplear ese modelo. Todos los registros 
de segmento se pueden llenar con el mismo selector, cuyo descriptor tiene Base = O y Límite igual al 
máximo. La distancia de instrucción será entonces la dirección lineal, utilizando un solo espacio de 
direcciones; en efecto, paginación normal. 

Considerando todo, hay que felicitar a los diseñadores de Pentium. Dados los objetivos opuestos 
de implementar paginación pura, segmentación pura y segmentos paginados, y al mismo tiempo mantener 
la compatibilidad con el 286, y además hacer todo esto de manera eficiente, el diseño resultante es 
sorprendentemente sencillo y aseado. 

Aunque hemos cubierto la arquitectura completa de la memoria virtual Pentium, si bien 
brevemente, vale la pena decir unas palabras acerca de la protección, ya que este tema está íntimamente 
relacionado con la memoria virtual. Así como el esquema de memoria virtual sigue de cerca el modelo 
MULTICS, lo mismo sucede con el sistema de protección. El Pentium maneja cuatro niveles de 
protección, siendo el O el más privilegiado y el 3 el menos privilegiado. Éstos se muestran en la Fig. 4-31. 
En cada instante, un programa en ejecución está en un nivel dado, indicado por un campo de dos bits en su 
PSW. Cada segmento del sistema también tiene un nivel. 

En tanto un programa se limite a usar segmentos en su propio nivel, todo fúncionará 
perfectamente. Se permiten intentos por acceder a datos en un nivel superior, pero los intentos por 
acceder a datos en un nivel inferior son ilegales y causan trampas. Los intentos por invocar 
procedimientos en un nivel distinto (más alto o más bajo) están permitidos, pero de una forma 
Cuidadosamente controlada. Para efectuar una llamada intemivel, la ins trucción CALL debe contener un 
selector en lugar de una dirección. Este selector designa un descriptor llamado puerta de 
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llamada que da la dirección del procedimiento por invocar. Por tanto, no es posible saltar a mitad de un 
segmento de código arbitrario en un nivel distinto. Sólo pueden usarse los puntos de entrada oficiales. Los 
conceptos de niveles de protección y puertas de llamada se aplicaron por primera vez en MULTICS, 
donde se veían como anillos de protección. 

Una aplicación típica de este mecanismo se sugiere en la Fig. 4-31. En el nivel O, encontramos el 
kemel del sistema operativo, que se encarga de E/S, administración de memoria y otras cuestiones críticas. 
En el nivel 1 está presente el manejador de llamadas al sistema. Los programas usuario pueden invocar 
procedimientos aquí para que se ejecuten llamadas al sistema, pero si puede invocarse una lista específica 
y protegida de procedimientos. El nivel 2 contiene procedimientos de biblioteca, posiblemente 
compartidos entre muchos programas en ejecución. Los programas usuario pueden invocar estos 
procedimientos y leer sus datos, pero no pueden modificarlos por último, los programas de usuario se 
ejecutan en el nivel 3, que tiene la menor protección. 

Las trampas y las interrupciones emplean un mecanismo similar a las puertas de llamada; el 
también hacen referencia a descriptores, en lugar de direcciones absolutas, y estos descriptores apuntan a 
procedimientos específicos que han de ejecutarse. El campo Tipo de la Fig. 4- distingue entre segmentos 
de código, segmentos de datos y las diversas clases de puertas. 

4.7 GENERALIDADES DE ADMINISTRACIÓN DE MEMORIA EN MINIX 

La administración de memoria en MINIX es sencilla: no se emplea ni paginación ni intercambio. El 
administrador de memoria mantiene una lista de agujeros ordenados en orden por dirección memoria. 
Cuando se necesita memoria, sea a causa de una llamada al sistema FORK o EXBC,i 
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examina la lista de agujeros empleando primer ajuste en busca de un agujero con el tamaño suficiente. 
Una vez que un proceso se ha colocado en la memoria, permanece en el mismo lugar hasta terminar; 
nunca se intercambia a disco y nunca se traslada a otro lugar de la memoria. Además, el área asignada 
nunca crece ni se encoge. 

Esta estrategia amerita una explicación. Son tres los factores que la justifican: (1) la idea de que 
MINIX es para computadoras personales, no para sistemas grandes de tiempo compartido, (2) el deseo de 
hacer que MINIX funcione en todas las IBM PC y (3) el deseo de facilitar la implementación del sistema 
en otras computadoras pequeñas. 

El primer factor implica que, en promedio, el número de procesos en ejecución será pequeño, y 
por lo regular habrá suficiente memoria para contener todos los procesos, con espacio de sobra. En tal 
caso no se necesitaría intercambiar. Dado que el intercambio hace más complejo el sistema, su ausencia da 
lugar a código más sencillo. 

El deseo de hacer que MINIX se ejecute en todas las computadoras compatibles con IMB PC 
también tuvo un impacto considerable sobre el diseño de la administración de memoria. Los sistemas más 
sencillos de esta familia usan el procesador 8088, cuya arquitectura de administración de memoria es muy 
primitiva. Este procesador no reconoce la memoria virtual en ninguna de sus formas y ni siquiera detecta 
un desbordamiento de pila, defecto que tiene implicaciones importantes para la forma en que se organizan 
los procesos en la memoria. Estas limitaciones no existen en diseños posteriores que usan los procesadores 
80386, 80486 o Pentium. Sin embargo, si aprovechara estas capacidades MINIX sería incompatible con 
muchas máquinas del extremo inferior que todavía están en uso. 

El aspecto de transportabilidad es un argumento en favor de un esquema de administración de 
memoria lo más sencillo posible. Si MINIX usara paginación o segmentación, sería difícil, si no 
imposible, trasladarlo a máquinas que no contaran con estas capacidades. Al postular un mínimo de 
supuestos respecto a lo que el hardware puede hacer, se multiplica el número de las máquinas a las que 
MINIX puede trasladarse. 

Otro aspecto inusual de MINIX es la forma como se implementa la administración de memoria. 
Esta fúnción no forma parte del kemel, sino que corre por cuenta del proceso administrador de memoria, 
que se ejecuta en el espacio de usuario y se comunica con el kemel mediante el mecanismo de mensajes 
estándar. La posición del administrador de memoria en el nivel de servidores se muestra en la Fig. 2-26. 

Sacar el administrador de memoria del kemel es un ejemplo de la separación de política y 
mecanismo. Las decisiones acerca de cuál proceso se colocará en qué lugar de la memoria I (política) son 
tomadas por el administrador de memoria. El establecimiento de mapas de memoria reales para los 
procesos (mecanismo) es efectuado por la tarea del sistema, dentro del I kemel. Esta división hace que sea 
relativamente fácil modificar la política de administración de i memoria (algoritmos, etc.), sin tener que 
alterar las capas inferiores del sistema operativo. 

La mayor parte del código del administrador de memoria se dedica a manejar las llamadas al 
sistema de MINIX que implican administración de memoria, principalmente FORK y EXEC, no sólo a 
manipular listas de procesos y agujeros. En la siguiente sección examinaremos la organización de h 
memoria, y en secciones subsecuentes veremos a grandes rasgos cómo las llamadas al sistema e implican 
administración de memoria son procesadas por el administrador de memoria. 
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4.7.1 Organización de la memoria 

Los procesos MINIX sencillos usan espacios I y D combinados, en los que todas las partes de proceso 
(texto, datos y pila) comparten un bloque de memoria que se asigna y libera como una unidad. También es 
posible compilar los procesos de modo que usen espacios I y D independientes. Por claridad, se explicará 
primero la asignación de memoria para el modelo más sencillo. LO! procesos que usan espacios I y D 
independientes pueden aprovechar la memoria con mayor eficiencia, pero las cosas se complican. 
Analizaremos las complicaciones después de bosquejare caso más sencillo. 

Se asigna memoria en MINIX en dos ocasiones. Primero, cuando se bifurca un proceso, se asigna 
la cantidad de memoria que el hijo necesita. Segundo, cuando un proceso cambia si imagen de memoria 
mediante la llamada al sistema EXEC, la imagen antigua se devuelve a la lista libre como un agujero, y se 
asigna memoria para la nueva imagen, la cual puede estar en una parte de memoria distinta de la memoria 
liberada. La posición dependerá de dónde se encuentre un agujero apropiado. También se libera memoria 
cuando un proceso termina, ya sea porque salió (porque fue cancelado por una señal. 

La Fig. 4-32 muestra ambas formas de asignar memoria. En la Fig. 4-32(a) vemos dos procesos, A 
y B, en la memoria. Si A bifurca, obtenemos la situación de la Fig. 4-32(b). El hijo a una copia exacta de 
A. Si el hijo ahora ejecuta el archivo C, la memoria se verá como en la Fig 4-32(c). La imagen del hijo es 
sustituida por C. 



Figura 4-32. Reparto de memoria, (a) Originalmente, (b) Después de un FORK. (c) Después 
de que el hijo realiza un EXEC. Las regiones sombreadas indican memoria desocupada. El 
proceso es un proceso de I&D común. 


Cabe señalar que la memoria que ocupaba el hijo es liberada antes de que se asigne la nueva 
memoria para C, así que C puede usar la memoria del hijo. De esta forma, una serie de pares FORB y 
EXEC (como cuando el shell establece un conducto o tubería) tiene como resultado que todflt los procesos 
estén adyacentes, sin agujeros entre ellos, como habría sucedido si la nueva memo» ría se asignara antes 
de liberarse la memoria anterior. 

Cuando se asigna memoria, ya sea por la llamada al sistema FORK o por EXEC, una parte de ella 
es ocupada por el nuevo proceso. En el primer caso, la cantidad que se toma es idéntica a la que 
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tiene el proceso padre. En el segundo caso, el administrador de memoria toma la cantidad especificada en 
la cabecera del archivo que se ejecuta. Una vez efectuada esta asignación, jamás se le asigna al proceso 
más memoria total. 

Lo que hemos dicho hasta ahora aplica a programas que han sido compilados con espacios I y D 
combinados. Los programas con espacio I y D separado aprovechan un modo ampliado de administración 
de memoria llamado texto compartido. Cuando un proceso de este tipo ejecuta FORK, sólo se asigna la 
cantidad de memoria requerida para una copia de los datos y la pila del nuevo proceso. Tanto el padre 
como el hijo comparten el código ejecutable que el padre ya está usando. Cuando semejante proceso 
realiza un EXEC, se examina la tabla de procesos para determinar si otro proceso ya está usando el código 
ejecutable requerido. Si alguno lo está haciendo, sólo se asigna memoria para los datos y pila nuevos, y se 
comparte el texto que ya está en la memoria. La compartición de texto complica la terminación de un 
proceso. Cuando un proceso termina siempre libera la memoria ocupada por sus datos y su pila, pero sólo 
libera la memoria ocupada por su segmento de texto después de que una búsqueda en la tabla de procesos 
revela que ningún otro proceso vigente está compartiendo esa memoria. Así, podría asignarse más 
memoria a un proceso cuando inicia que la que se libera cuando termina, si carga su propio texto al iniciar 
pero dicho texto está siendo compartido por uno o más procesos aparte cuando el primer proceso termina. 



El segmento de pila crece hacia abajo 

El segmento de datos crece hacia arriba (o hacia 
abajo) cuando se efectúan llamadas BRK 


Figura 4-33. (a) Un programa tal como está almacenado en un archivo de disco, (b) Organiza¬ 
ción de memoria interna para un solo proceso. En ambas partes de la figura la dirección más 
baja del disco o de la memoria está abajo y la dirección más alta está arriba. 


La Fig. 4-33 muestra cómo se almacena un programa en forma de archivo en disco y cómo éste se 
transfiere a la organización de memoria interna de un proceso MINIX. La cabecera del archivo contiene 
información acerca de los tamaños de las diferentes partes de la imagen, así como el tamaño total. En la 
cabecera de un programa con espacio I y D común, un campo especifica el tamaño total de las partes de 
texto y de datos; estas partes se copian directamente en la imagen de memoria. La parte de datos de la 
imagen se amplía en la cantidad especificada en el campo los de la cabecera. Esta área se despeja de modo 
que sólo contenga ceros y se utiliza para datos estáticos no inicializados. La cantidad total de memoria por 
asignar se especifica con el 
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campo total de la cabecera. Si, por ejemplo, un programa tiene 4K de texto, 2K de datos más bsf y 1K de 
pila, y la cabecera indica asignar 40K en total, el espacio de memoria desocupada entre el segmento de 
datos y el segmento de pila será de 33K. Un archivo de programa en disco también puede contener una 
tabla de símbolos. Ésta sirve para fines de depuración y no se copia en la memoria. 

Si el programador sabe que la memoria total requerida para el crecimiento combinado de los 
segmentos de datos y de pila para el archivo a.out es de como máximo 10K, puede emitir el comando 

chmem = 10240 a.out 

que modifica el campo de cabecera de modo que cuando se emita EXEC el administrador de memoria 
asigne un espacio de 10240 bytes más grande que la suma de los segmentos de texto y de datos iniciales. 
En el ejemplo anterior, se asignaría un total de 16K en todos los EXEC subsecuentes del archivo. De esta 
cantidad, el 1K superior se usará para la pila, y habrá 9K en el espacio, donde podrá utilizarse para el 
crecimiento de la pila, del área de datos o de ambas cosas. 

En el caso de un programa con espacio I y D separado (lo que se indica con un bit en la cabecera 
que el enlazador enciende), el campo total de la cabecera aplica sólo al espacio combinado de datos y pila. 
Un programa con 4K de texto, 2K de datos, 1K de pila y un tamaño total de 64K recibirá 68K (4K de 
espacio para instrucciones y 64K de espacio para datos), dejando 61K que el segmento de datos y la pila 
pueden consumir durante la ejecución. La frontera del segmento de datos sólo puede desplazarse con la 
llamada al sistema BRK. Lo único que hace BRK es determinar si el nuevo segmento de datos choca o no 
contra el apuntador a la pila actual y, si no choca, anota el cambio en ciertas tablas internas. Esto se 
efectúa totalmente dentro de la memoria originalmente asignada al proceso; el sistema operativo no asigna 
memoria adicional. Si el nuevo segmento de datos choca contra la pila, la llamada fracasa. 

Se escogió tal estrategia con objeto de poder ejecutar MINIX en una IBM PC con un procesador 
8088, que no vigila el desbordamiento de la pila en hardware. Un programa de usuario puede meter 
cuantas palabras quiera en la pila sin que el sistema operativo se dé cuenta de ello. En computadoras con 
hardware de administración de memoria más avanzado, se asigna inicialmente a la pila cierta cantidad de 
memoria. Si la pila trata de crecer más allá de este espacio, ocurre una trampa al sistema operativo y el 
sistema asigna otra porción de memoria a la pila, si es posible, Esta trampa no existe en el 8088, lo que 
hace peligroso tener a la pila adyacente a otra cosa que no sea un trozo grande de memoria desocupada, 
pues la pila puede crecer rápidamente y sin previo ¡ aviso. MINIX se diseñó de modo que cuando se 
implemente en una computadora con mejor | administración de memoria no sea difícil modificar el 
administrador de memoria. 

Ésta es una buena ocasión para mencionar un posible problema de semántica. Cuando usamos la 
palabra "segmento" nos referimos a un área de memoria definida por el sistema operativo, Los 
procesadores Intel 80x86 tienen un conjunto de "registros de segmento" internos y (en los procesadores 
más avanzados) "tablas de descriptores de segmentos" que proporcionan apoyo de hardware para los 
"segmentos". El concepto de "segmento" de los diseñadores de hardware Intel es similar, pero no siempre 
idéntico, a los segmentos empleados y definidos por MINIX. Todas las referencias a segmentos en este 
texto deben interpretarse como referencias a áreas de memoria 
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delineadas por estructuras de datos de MINIX. Nos referiremos explícitamente a los registros de segmento 
o descriptores de segmento cuando hablemos acerca del hardware. 

Podemos generalizar esta advertencia. Los diseñadores de hardware a menudo tratan de 
proporcionar apoyo para los sistemas operativos que piensan que se usarán en sus máquinas, y la 
terminología empleada para describir registros y otros aspectos de la arquitectura de un procesador suele 
reflejar la idea que se tiene de cómo se utilizarán las capacidades. Tales capacidades con frecuencia 
resultan útiles para el implementador de un sistema operativo, pero no siempre se utilizan de la forma 
prevista por el diseñador de hardware. Esto puede dar pie a malentendidos cuando la misma palabra tiene 
diferente significado si se usa para describir un aspecto de un sistema operativo o del hardware 
subyacente. 

4.7.2 Manejo de mensajes 

Al igual que los demás componentes de MINIX, el administrador de memoria se controla mediante 
mensajes. Una vez que el sistema se ha inicializado, el administrador de memoria ingresa en su ciclo 
principal, que consiste en esperar un mensaje, atender la solicitud contenida en el mensaje y enviar una 
respuesta. En la Fig. 4-34 se muestra la lista de tipos de mensaje permitidos, sus parámetros de entrada y 
el valor que se devuelve en el mensaje de respuesta. 

Es evidente que FORK, EXIT, WAIT, WAITPID, BRK y EXEC están muy relacionadas con la 
asignación y liberación de memoria. Las llamadas KILL, ALARM y PAUSE están relacionadas con las 
señales, lo mismo que SIGACTION, SIGSUSPEND, SIGPENDING, SIGMASK y SIGRETURN. Éstas 
también pueden afectar lo que está en la memoria porque cuando una señal mata un proceso la memoria 
que éste ocupaba se libera. REBOOT tiene efectos en todo el sistema operativo, pero su primera tarea es 
enviar señales para terminar todos los procesos de forma controlada, así que el administrador de memoria 
es un buen lugar para tenerlo. Las siete llamadas GET/SET nada tienen que ver con la administración de 
memoria, y tampoco con el sistema de archivos, pero tenían que estar ya sea en el sistema de archivos o en 
el administrador de memoria, pues todas las llamadas al sistema son manejadas por uno o por el otro. 
Dichas llamadas se colocaron aquí porque el sistema de archivos ya era muy grande de por sí. PTRACE, 
que se utiliza en depuración, está aquí por la misma razón. 

El último mensaje, KSIG, no es una llamada al sistema; es el tipo de mensaje empleado por el 
kemel para informar al administrador de memoria de una señal que se origina en el kemel, como SIGINT, 
SIGQUIT O SIGALRM. 

Aunque hay una rutina de biblioteca sbrk, no existe una llamada al sistema SBRK. La rutina de 
biblioteca calcula la cantidad de memoria requerida sumando al tamaño actual el incremento o decremento 
especificado como parámetro, y luego efectúa una llamada BRK para fijar el tamaño. De forma similar, no 
existen llamadas al sistema individuales para geteuid y getegid. Las llamadas GETUID y GETGID 
devuelven los identificadores tanto efectivo como real. De forma similar, GETPID devuelve el pid tanto 
del proceso invocador como de su padre. 

Una estructura de datos clave empleada para el procesamiento de mensajes es la tabla call vec 
declarada en table.c (línea 16515), la cual contiene apuntadores a los procedimientos que manejan ' los 
diversos tipos de mensajes. Cuando llega un mensaje al administrador de memoria, el ciclo 
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Figura 4-34. Los tipos de mensajes, parámetros de entrada y valores de respuesta empleados 
para comunicarse con el administrador de memoria. 


principal extrae el tipo de mensaje y lo coloca en la variable global mmcall. Este valor se u|| después 
como índice para entrar en callvec y encontrar el apuntador al procedimiento que nuffel mensaje recién 
llegado. A continuación se invoca ese procedimiento para ejecutar la llamada al sistema. El valor que se 
devuelve se envía de vuelta al invocador en el mensaje de respuesta) informar del éxito o el fracaso de la 
llamada. Este mecanismo es similar al de la Fig. 1-16, sóló| en el espacio de usuario en lugar del kemel. 

;J 






























SEC. 4.7 GENERALIDADES DE ADMINISTRACIÓN DE MEMORIA EN MINIX 363 

4.7.3 Estructuras de datos y algoritmos del administrador de memoria 

El administrador de memoria tiene dos estructuras de datos clave: la tabla de procesos y la tabla de 
agujeros. A continuación las veremos por tumo. 

En la Fig. 2-4 vimos que algunos campos de la tabla de procesos son necesarios para la administración de 
procesos, otros para la administración de memoria y otros más para el sistema de archivos. En MINIX, 
cada una de estas tres partes del sistema operativo tiene su propia tabla de procesos, misma que contiene 
sólo los campos que esa parte necesita. Las entradas corresponden exactamente, a fin de simplificar las 
cosas. Así, la ranura k de la tabla del administrador de memoria se refiere al mismo proceso que la ranura 
k de la tabla del sistema de archivos. Cuando se crea o se destruye un proceso, las tres partes actualizan 
sus tablas de modo que reflejen la nueva situación, a fin de mantenerlas sincronizadas. 

La tabla de procesos del administrador de memoria se llama mproc; su definición está en/usr/ 
src/mm/mproc.h. Esta tabla contiene todos los campos relacionados con la asignación de memoria e un 
proceso, así como ciertos elementos adicionales. El campo más importante es el arreglo p_seg, que tiene 
tres entradas, para los segmentos de texto, datos y pila, respectivamente. Cada entrada es una estructura 
que contiene la dirección virtual, la dirección física y la longitud del segmento, todas medidas en clics, no 
en bytes. El tamaño de un clic depende de la implementación; para el MINIX estándar es 256 bytes. Todos 
los segmentos deben comenzar en una frontera de clic y ocupar un número entero de clics. 

El método empleado para registrar la asignación de memoria se muestra en la Fig. 4-35. En esta 
figura tenemos un proceso con 3K de texto, 4K de datos, un espacio de 1K y luego una pila de 2K, para 
una asignación total de memoria de 10K. En la Fig. 4-35(b) vemos en qué consisten los campos virtual, 
físico y de longitud para cada uno de los tres segmentos, suponiendo que el proceso no tiene espacio I y D 
separado. En este modelo, el segmento de texto siempre está vacío, y el segmento de datos contiene tanto 
texto como datos. Cuando un proceso hace referencia a la dirección virtual O, ya sea para saltar a ella o 
para leerla (es decir, como espacio deinstruccione o como espacio de datos), se usa la dirección física 
0x32000 (en decimal, 200K).Esta dirección está en el clic 0x320. 

Cabe señalar que la dirección virtual en la que comienza la pila depende inicialmente de la 
cantidad total de memoria asignada al proceso. Si se usara el comando chmem para modificar a cabecera 
de archivo a fin de contar con un área de asignación dinámica más grande (un espacio mayor entre los 
segmentos de datos y de pila), la siguiente vez que se ejecutara el archivo la pila comenzaría en una 
dirección virtual más alta. Si la pila se alarga en un clic, la entrada correspondiente a la pila debería 
cambiar de la tripleta (0x20, 0x340, 0x8) a la tripleta (OxIF, Ox33F, 0x9). 

El hardware del 8088 no tiene una trampa de límite de pila, y MINIX define la pila de modo tal 
que no dispare la trampa en los procesadores de 32 bits hasta que la pila ya haya sobreescrito el segmento 
de datos. Por tanto, este cambio no se efectuará sino hasta la siguiente llamada al astenia BRK, y entonces 
el sistema operativo leerá explícitamente SP y volverá a calcular las adas de los segmentos. En una 
máquina con trampa de pila, la entrada del segmento de pila se tía actualizar tan pronto como la longitud 
de la pila excediera la de su segmento. MINIX no i esto en los procesadores Intel de 32 bits, por razones 
que veremos a continuación. 
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208K (0x34000) 
207K (0x33c00) 


203K (0x32c00) 

200K (0x32000) 



Figura 4-35. (a) Un proceso en la memoria, (b) Su representación de memoria con espacio 
y D no separado, (c) Su representación con espacio I y D separado. 


Ya mencionamos que las labores de los diseñadores de hardware no siempre producen lo que el 
diseñador de software necesita. Incluso en modo protegido en un Pentium, MINIX no atrapa; cuando la 
pila se desborda de su segmento al crecer. Aunque en modo protegido el hardware Intel | detecta los 
intentos por acceder a memoria fuera de un segmento (definido por un descriptor | de segmento como el de 
la Fig. 4-28), en MDMIX el descriptor de segmento de datos y el descriptor de segmento de pila siempre 
son idénticos. Los segmentos de datos y de pila definidos por MiNff utilizan cada uno una parte de este 
espacio, de modo que cualquiera de ellos, o ambos, se pueden expandir hacia la brecha que los separa. Sin 
embargo, sólo MINIX puede administrar esto. La CPU; no tiene forma de detectar errores relativos a la 
brecha, ya que en lo que al hardware concien dicha brecha es una paite válida tanto del área de datos como 
del área de pila. Desde luego, i hardware puede detectar un error muy grande, como un intento por acceder 
a memoria fuera c área combinada de datos-hueco-pila. Esto protege a un proceso de los errores de otro 
proces pero no basta para proteger a un proceso de sí mismo. 

Aquí se tomó una decisión de diseño. Reconocemos que podría haber argumentos válidos! favor 
de abandonar el segmento compartido definido por hardware que permite a MINIX reasignar 
dinámicamente el área de la brecha. La alternativa, usar el hardware para definir segmentos de datos y de 
pila que no se traslapen, ofrecería un poco más de protección contra ciertos erre pero haría que MINIX 
estuviera más hambriento de memoria. El código fuente está disponible para cualquier persona que desee 
evaluar el otro enfoque. 

La Fig. 4-35(c) muestra las entradas de segmento para la organización de memoria de lal 4-35(a) 
con espacio I y D separado. Aquí los segmentos tanto de texto como de datos tienen) longitud mayor que 
cero. El arreglo mp seg que se muestra en la Fig. 4-35(b) o (c) se utili| primordialmente para transformar 
direcciones virtuales en direcciones de memoria física. ~ 
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una dirección virtual y el espacio al que pertenece, resulta sencillo determinar si la dirección virtual es 
válida o no (es decir, si queda dentro de un segmento) y, si es válida, a qué dirección física corresponde. 
El procedimiento de kemel umap realiza esta transformación para las tareas de E/S y para el copiado en y 
desde el espacio de usuario, por ejemplo. 


Virtual Física Longitud 


Proceso 1 
(a) 



f 


Dalos 
(PrOC 1) 


0x3(3400 

0x3d000 


0x3c000 

0x34800 


0x34000 

Ox33cOO 


Virtual Física Longitud 


Datos 

Texto 


Proceso 2 
(c) 


Figura 4-36. (a) El mapa de memoria de un proceso con espacio 1 y D separado, como en la 
figura anterior, (b) La organización en la memoria después de que se inicia un segundo proceso, 
ejecutando la misma imagen de programa con texto compartido, (c) El mapa de memoria del 
segundo proceso. 


El contenido de las áreas de datos y de pila pertenecientes a un proceso puede cambiar durante la 
ejecución de éste, pero el texto no cambia. Es común que varios procesos estén ejecutando copias del 
mismo programa; por ejemplo, varios usuarios podrían estar ejecutando el mismo shell. La eficiencia de 
memoria mejora si se emplea texto compartido. Cuando EXEC está a punto decargar un proceso, abre el 
archivo que contiene la imagen en disco del programa que se va a cargar ,y lee la cabecera del archivo. Si 
el proceso emplea espacio I y D separado, se examinan los icampos mpdev, mpino y mpctíme de cada 
ranura de mproc. Estos contienen los números de dispositivo y de nodo-i y los tiempos de cambio de 
situación de las imágenes que están siendo ejecutadas por otros procesos. Si se determina que un proceso 
que ya se cargó está ejecutando el 
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mismo programa que está a punto de cargarse, no habrá necesidad de asignar memoria para otra copia del 
texto. En vez de ello, se inicializa la porción mp_seg[T] del mapa de memoria del nuevo proceso de modo 
que apunte al mismo lugar en el que ya está cargado el segmento de texto, y sólo se establecen las 
porciones de datos y de pila en una nueva asignación de memoria. Esto se muestra en la Fig. 4-36. Si el 
programa usa espacio I y D combinado o no se encuentra un proceso que esté ejecutando el mismo 
programa, la memoria se reparte como se muestra en la Fig. 4-35 y el texto y los datos para el nuevo 
proceso se copian en ella desde el disco. 

Además de la información sobre segmentos, mproc también contiene el identificador de proceso 
(pid) del proceso mismo y de su padre, los uids y gids (tanto reales como efectivos), información referente 
a las señales y la situación de salida, si el proceso ya terminó pero su padre todavía no efectúa un WAIT 
por él. 

La otra tabla importante del administrador de memoria es la de agujeros, hole, definida en alloc.c, 
que \ista todos los agujeros de memoria erv orden de dirección creciente. Los espacios entre los segmentos 
de datos y de pila no se consideran agujeros; ya han sido asignados a procesos, así que no están contenidos 
en la lista de agujeros libres. Cada entrada de la lista de agujeros tiene tres campos: la dirección base del 
agujero en clics, la longitud del agujero en clics y un apuntador a la siguiente entrada de la lista. La lista 
sólo tiene enlaces sencillos, así que es fácil encontrar el siguiente agujero a partir de cualquier agujero 
dado, pero para encontrar el agujero anterior hay que examinar toda la lista desde el principio hasta llegar 
al agujero en cuestión. 

La razón por la que se registra todo acerca de los segmentos y agujeros en clics en vez de bytes es 
sencilla: resulta mucho más eficiente. En modo de 16 bits, se usan enteros de 16 bits para registrar 
direcciones de memoria, así que con clics de 256 bytes se puede manejar hasta 16 MB de memoria. En 
modo de 32 bits, los campos de dirección pueden hacer referencia a hasta 240 bytes, es decir, 1024 
gigabytes. 

Las principales operaciones de la lista de agujeros son asignar una porción de memoria de cierto 
tamaño y devolver una asignación existente. Para asignar memoria, se realiza una búsqueda en la lista de 
agujeros, comenzando por el agujero con la dirección más baja, hasta encontrar un agujero con el tamaño 
suficiente (primer ajuste). A continuación se asigna el segmento reduciendo el agujero en la cantidad 
necesaria para el segmento o, en los raros casos en que el ajuste e»' exacto, eliminando el agujero de la 
lista. Este esquema es rápido y sencillo pero adolece tantoát| una pequeña cantidad de fragmentación 
interna (se pueden desperdiciar hasta 255 bytes del clisé final, ya que siempre se toma un número entero 
de clics) como de fragmentación extema. 

Cuando un proceso ter mi na y se realiza el aseo, su memoria de datos y de pila se coloca vuelta en 
la lista libre. Si el proceso usa I y D común, con esto se libera toda su memoria, ya ( A *aiü-, r>TO A camai& 
nunca tienen una asignación de memoria aparte para texto. Si el programa u; A V> ,A Y&x-iAo'2» "5 
A \v A \ws A >s, A A &\'\ YásVí. A i, •'$W>W&Q'& \esévs. o A t -wwgffls. 'siwa A owáo compartiendo el texto, 
también se devolverá la memoria asignada a texto. Puesto que en el c texto compartido las regiones de 
texto y de datos no necesariamente son contiguas, se p devolver dos regiones de memoria. Para cada 
región devuelta, si cualquiera de los vecinos región, o ambos, son agujeros, se fúsionan, de modo que 
nunca hay agujeros adyacentes., número, ubicación y tamaño de los agujeros varían continuamente 
durante la operación del ma. Si todos los procesos de usuario han terminado, toda la memoria disponible 
estará 
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lista para ser asignada. Esto no implica necesariamente que sólo habrá un agujero, pues la memoria física 
puede estar interrumpida por regiones que el sistema operativo no puede utilizar, como en los sistemas 
compatibles con IBM en los que la memoria sólo de lectura (ROM) y la memoria reservada para 
transferencias de E/S separan la memoria utilizable por debajo de la dirección 640K de la memoria que 
está por arriba de 1K. 

4.7.4 Las llamadas al sistema FORK, EXIT y WAIT 

Cuando se crean o destruyen procesos, hay que asignar o liberar memoria. Además, es preciso actualizar 
la tabla de procesos, incluidas las partes que mantienen el kemel y el sistema de archivos. El administrador 
de memoria coordina toda esta actividad. La creación de procesos se efectúa con FORK, y consta de la 
serie de pasos que se muestran en la Fig. 4-37. 



Figura 4-38. Los pasos requeridos para llevar a cabo la llamada al sistema EXBC. 


Es difícil y poco recomendable detener una llamada FORK antes de terminar, así que el 
administrador de memoria mantiene en todo momento una cuenta del número de procesos existentes| a fin 
de poder determinar fácilmente si hay una ranura disponible en la tabla de procesos. Si la| tabla no está 
llena, se intenta asignar memoria para el hijo. Si el programa tiene espacio I y D separado, sólo se solicita 
suficiente memoria para las nuevas asignaciones de datos y pila. Si este paso también tiene éxito, está 
garantizado que el FORK fúncionará. A continuación se llena la memoria recién asignada, se localiza una 
ranura de proceso y se llena, se escoge un pid y se ¡informa a las demás partes del sistema que se creó un 
proceso nuevo. 

Un proceso termina por completo una vez que han ocurrido dos sucesos: (1) el proceso en sí (lió 
(o fúe cancelado por una señal) y (2) su padre ejecutó una llamada al sistema WAIT para averiguar qué 
sucedió. Un proceso que ha salido o que ha sido cancelado, pero cuyo padre ndavía) no ha realizado un 
WAIT por él, queda en una especie de animación suspendida, a veces EDonúnada estado zombi. El 
proceso no puede ser planificado y tiene apagado su temporizador A alarma (si estaba encendido), pero no 
se retira de la tabla de procesos. Su memoria queda 
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liberada. El estado zombi es temporal y casi nunca dura mucho. Cuando el padre fin alment ejecuta el 
WAIT, la ranura de la tabla de procesos se libera y se informa de ello al sistema de archivos y al kemel. 

Surge un problema si el padre del proceso que está saliendo ya está muerto. Si no se realizar 
alguna acción especial, el proceso saliente seguiría como zombi indefinidamente. En vez de ellos las 
tablas se modifican para convertirlo en hijo del proceso init. Cuando el sistema arranca, iniíle el archivo 
/etc/ttytab para obtener una lista de todas las terminales, y después bifurca un procesi de inicio de sesión 
para manejar cada uno. A continuación, init se bloquea, esperando que lo procesos terminen. De esta 
forma, los zombis huérfanos se eliminan rápidamente. 

4.7.5 La llamada al sistema EXEC 

Cuando se teclea un comando en una terminal, el shell bifurca un nuevo proceso, que entonce ejecuta el 
comando solicitado. Podría haber sido posible tener una sola llamada al sistema qui efectuara tanto FORK 
como EXEC a un tiempo, pero se prefirió tener dos llamadas por una razón excelente: facilitar la 
implementación de la redirección de E/S. Cuando el shell bifurca, si se redirigf la entrada estándar, el hijo 
cierta la entrada estándar y luego abre la nueva entrada estándar antei de ejecutar el comando. De este 
modo, el proceso recién iniciado hereda la entrada estánda redirigida. La salida estándar se maneja de la 
misma forma. 

EXEC es la llamada al sistema más compleja de MINIX, pues debe sustituir la imagen de 
memoria actual por una nueva, lo que incluye el estableci mi ento de una nueva pila. EXEC realizar este 
trabajo en una serie de pasos, los cuales se listan en la Fig. 4-38. 


1. Verifica permisos —¿es ejecutable el archivo? 

2. Lee la cabecera para obtener los tamarVos de segmento y total. 

3. Obtiene los argumentos y el enlomo del invocador. 

4 Asigna nueva mamona y libera la memoria vieja que no se necesite. 

5. Copia la pila en la nueva imagen de memoria. 

6 Copia el segmento de datos (y tal vez el de texto) en la nueva imagen de memoria. 

7 Verifica y maneja los bits setuid y selgid. 

8 Corrige la entrada de la labia de procesos 

9 Informa ai kemel que el proceso es ejecutable. 

Figura 4-38. Los pasos requeridos para llevar a cabo la llamada al sistema EXEC 

Cada paso consiste, a su vez, en pasos aún más pequeños, algunos de los cuales puedetl fracasar. 
Por ejemplo, podría ser que no hubiera suficiente memoria disponible. El orden en que»¡ efectúan las 
pruebas se escogió con cuidado a fin de asegurarse de que la nueva imagen de mem A i ria no se liberará 
antes de tener la certeza de que el EXEC tendrá éxito, con objeto de evitar te] embarazosa situación de no 
poder establecer una nueva imagen de memoria y tampoco tener ti 
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antigua para regresar a ella. Normalmente, EXEC no regresa, pero si falla el proceso invocador debe 
obtener de nuevo el control, con una indicación de error. 

Hay unos cuantos pasos de la Fig. 4-38 que merecen un comentario más amplio. Primero está la 
cuestión de si hay o no espacio suficiente. Después de determinar cuánta memoria se necesita, lo que 
requiere determinar si se puede compartir o no la memoria de texto de otro proceso, se examina la lista de 
agujeros para comprobar si hay suficiente memoria física antes de liberar la memoria anterior. Si la 
memoria vieja se liberara primero y no hubiera suficiente memoria, sena difícil recuperar la imagen 
anterior. 

Sin embargo, esta prueba es demasiado estricta; a veces rechaza llamadas EXEC que, de hecho, 
podrían tener éxito. Supongamos, por ejemplo, que el proceso que efectúa la llamada EXEC ocupa 20K y 
que su texto no es compartido por ningún otro proceso. Supongamos, además, que hay un agujero de 30K 
disponible y que la nueva imagen requiere 50K. Al efectuar la prueba antes de liberar, descubriremos que 
sólo hay 30K disponibles y rechazaremos la llamada. Si hubiéramos liberado primero, podríamos haber 
tenido éxito, dependiendo de si el nuevo agujero de 20K está adyacente a, y por tanto ahora fusionado con, 
el agujero de 30K o no. Una implementación más avanzada podría manejar esta situación un poco mejor. 

Otra mejora posible sería buscar dos agujeros, uno para el segmento de texto y otro para el 
segmento de datos, si el proceso que se llamó con EXEC tiene espacio I y D separado. No es necesario 
que los segmentos sean contiguos. 

Un problema más sutil es si el archivo ejecutable cabe o no en el espacio de direcciones virtual. El 
problema es que la memoria se asigna no en bytes, sino en clics de 256 bytes. Cada clic debe pertenecer a 
un solo segmento, y no puede ser, por ejemplo, mitad datos y mitad pila, porque toda la administración de 
memoria se efectúa en clics. 

Para ver cómo esta restricción puede causar problemas, observemos que el espacio de direcciones 
en los sistemas de 16 bits (8088 y 80286) está limitado a 64K, el cual puede dividirse en 256 clics. 
Supongamos que un programa con espacio I y D separado tiene 40 000 bytes de texto, 32 770 bytes de 
datos y 32 760 bytes de pila. El segmento de datos ocupa 129 clics, de los cuales el último sólo se utiliza 
parcialmente; de todos modos, el clic completo forma parte del segmento de datos. El segmento de pila 
tiene 128 clics. Juntos exceden 256 clics, y por tanto no pueden coexistir, a pesar de que el número de 
bytes requeridos sí cabe (apenas) en el espacio de direcciones virtual. En teoría, este problema existe en 
todas las máquinas cuyo tamaño de clic es mayor que un byte, pero en la práctica casi nunca ocurre en 
procesadores clase Pentium, ya que éstos permiten segmentos grandes (de 4 GB). 

Otra cuestión importante es la configuración de la pila inicial. La llamada de biblioteca que 
normalmente se usa para invocar EXEC con argumentos y un entorno es 

execve(name, argv, envp); 

donde ñame es un apuntador al nombre del archivo por ejecutar, argv es un apuntador a un arreglo de 
apuntadores, cada uno de los cuales apunta a un argumento, y envp es un apuntador a un arreglo de 
apuntadores, cada uno de los cuales apunta a una cadena de entorno. 

Sería muy fácil implementar EXEC colocando simplemente los tres apuntadores en el mensaje al 
administrador de memoria y dejando que él obtenga el nombre de archivo y los dos arreglos por 
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sí solo. Entonces, el administrador de memoria tendría que obtener cada argumento y cada cadena uno por 
uno. Hacerlo de esta forma requeriría al menos un mensaje a la tarea del sistema por cada argumento o 
cadena, y probablemente más, ya que el administrador de memoria no tiene forma de saber 
anticipadamente qué tan grande es cada uno. 

Para evitar el gasto extra de una gran cantidad de mensajes para leer todos estos componentes, se 
ha escogido una estrategia totalmente distinta. El procedimiento de biblioteca execve construye toda la 
pila inicial dentro de sí mismo y pasa su dirección base y tamaño al administrador de memoria. La 
construcción de la nueva pila dentro del espacio de usuario es muy eficiente, porque las referencias a los 
argumentos y cadenas sólo son referencias a memoria local, no a un espacio de direcciones diferente. 


Arreglo de 
entorno 



HOME = 'usr/ast 


Arreglo de 
argumentos 


0 



ge 

t.c 

ls 



52 

48 

44 

40 

36 

32 

28 

24 

20 

16 

12 


0 


(a) (b) 



F¡gura 4-39. la) Los arreglos que se pasan a execve. (b) La pila construida por execve. (c) La 
pila después de ser reubicada por el administrador de memoria, (d) La pila tal como main la ve 
al principio de la ejecución. 


A fin de hacer más claro este mecanismo, consideremos un ejemplo. Cuando un usuario teclea Is- 

I f.c g.c 

para el shell, éste interpreta el comando y luego efectúa la llamada 
execve("/bin/ls", argv, envp); 

al procedimiento de biblioteca. El contenido de los dos arreglos de apuntadores se muestra en la Fig. 4- 
39(a). Ahora, el procedimiento execve, dentro del espacio de direcciones del shell, construye 
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la pila inicial, como se muestra en la Fig. 4-39(b). Esta pila se copia posteriormente sin modificación al 
administrador de memoria durante el procesamiento de la llamada EXEC. 

Cuando la pila se copie finalmente al proceso de usuario, no se colocará en la dirección virtual 0. 
En vez de ello, se colocará al final de la asignación de memoria, determinado por el campo de tamaño de 
memoria total de la cabecera del archivo ejecutable. Por ejemplo, supongamos arbitrariamente que el 
tamaño total es de 8192 bytes, de modo que el último byte disponible para el programa está en la dirección 
8191. Es obligación del administrador de memoria reubicar los apuntadores dentro de la pila de modo que, 
cuando se le deposite en la nueva dirección, la pila tenga el aspecto que se muestra en la Fig. 4-39(c). 

Cuando se completa la llamada EXEC y el programa comienza a ejecutarse, la pila sí tendrá 
exactamente el aspecto de la Fig. 4-39(c), con el valor 8136 en el apuntador a la pila. Sin embargo, falta 
resolver otro problema. El programa principal del archivo ejecutado probablemente se declara con algo 
similar a esto: 

main(argc, argv, envp); 

En lo que al compilador de C concierne, main no es más que otra función. El compilador no sabe que 
main es especial, así que compila código para acceder a los tres parámetros bajo el supuesto de que éstos 
se pasarán empleando la convención de llamada estándar de C, con el último parámetro primero. Al ser un 
entero y dos apuntadores, se espera que los tres parámetros ocuparán las tres palabras que están justo antes 
de la dirección de retomo. Desde luego, la pila de la Fig. 4-39(c) no tiene para nada ese aspecto. 

La solución es que los programas no comiencen con main. En vez de ello, siempre se vincula en la 
dirección de texto O una pequeña rutina en lenguaje ensamblador llamada crtso, el procedimiento de 
inicio de tiempo de ejecución de C, con objeto de que sea la primera en obtener el control. La misión de 
crtso es meter tres palabras más en la pila y luego invocar main usando la instrucción de llamada estándar. 
Esto produce la pila de la Fig. 4-39(d) en el momento en que main empieza a ejecutarse. Así, se engaña a 
main haciéndole creer que se le invocó de la manera usual (en realidad, no es un engaño; sí se le invoca de 
esa manera). 

Si el programador se olvida de invocar exit al final de main, el control regresará a la rutina de 
inicio de tiempo de ejecución de C cuando main ter mi ne. Una vez más, el compilador sólo ve a main 
como un procedimiento ordinario y genera el código acostumbrado para regresar de él después de la 
última instrucción. Así, main regresa a su invocador, la rutina de inicio de tiempo de ejecución de C, que 
luego invoca ella misma exit. La mayor parte del código del crtso de 32 bits se muestra en la Fig. 4-40. 
Los comentarios deberán hacer obvio su funcionamiento. Lo único que se omitió es el código que carga 
los registros que se agregan a la pila y unas cuantas líneas que izan una bandera que indica si está presente 
un coprocesador de punto flotante o no. 

4.7.6 La llamada al sistema BRK 

Los procedimientos de biblioteca brk y sbrk sirven para ajusfar el límite superior del segmento dedatos. El 
primero toma un tamaño absoluto (en bytes) e invoca BRK. El segundo toma un incremento 
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push ecx 
push edx 
push eax 
push eax 
cali exit 
hit 


! poner en la pila entorno 
! poner en la pila argv 

! poner en la pila argccali main ! main(argc, argv, envp) 

! poner en la pila estado de salida 

! forzar a una trampa si exit falla 


Figura 4-40. La pane clave de la rutina de inicio de tiempo de ejecución de C. 


positivo o negativo para el tamaño actual, calcula el nuevo tamaño de segmento de datos, y luego invoca 
BRK. No existe una llamada al sistema SBRK. 

Una pregunta interesante es: "¿Cómo se mantiene sbrk al tanto del tamaño actual, para poda 
calcular el nuevo tamaño?" La respuesta es que una variable, brksize, siempre contiene el tamaño actual 
para que sbrk pueda encontrarlo. Esta variable se inicializa con un símbolo generado por el compilador 
que indica el tamaño inicial del texto más los datos (I y D no separados) o sólo los datos (I y D separados). 
El nombre y, de hecho, la existencia misma de tal símbolo depende del compilador y, por tanto, no lo 
veremos definido en ningún archivo de cabecera de los directorios de archivos fuente. El símbolo se 
define en la biblioteca, en el archivo hrksize.s. El lugar exacto donde se encuentra este archivo depende 
del sistema, pero siempre está en el mismo directorio que crtso.s. 

Para el administrador de memoria es fácil ejecutar BRK. Lo único que hay que hacer es verificar 
que todo quepa aún en el espacio de direcciones, ajustar las tablas e informarle al kemel. 


4.7.7 Manejo de señales 

En el capítulo 1 describimos las señales como un mecanismo para comunicar información aun proceso que 
no necesariamente está esperando entradas. Existe un conjunto definido de señales, y cada señal tiene una 
acción por omisión: ya sea terminar el proceso al que va dirigida o hacer caso omiso de la señal. El 
procesamiento de señales sería fácil de entender e implementar siestas fúeran las únicas alternativas. Sin 
embargo, los procesos pueden usar llamadas al sistema que alteran estas respuestas. Un proceso puede 
solicitar que se haga caso omiso de todas las señales (excepto la señal especial SIGKILL). Además, un 
proceso puede prepararse para atrapar una señal solicitando que se active un procedimiento manejador de 
señal interno al proceso, en lugar de la acción predeterminada para cualquier señal (con la excepción, otra 
vez, de SIGKILL). Así, desde ti punto de vista del programador, sólo hay dos momentos bien definidos en 
los que el sistema operativo maneja señales: una fase de preparación durante la cual un proceso puede 
modificar su, respuesta a una señal fútura y una fase de respuesta en la que se genera una señal y se realiza 
la» acción correspondiente. La acción puede ser la ejecución de un manejador de señales personalizado,; 

En realidad, existe una tercera fase. Cuando un manejador escrito por el usuario termina, una 
llamada al sistema especial efectúa limpieza y restaura el fúncionamiento normal del proceso all que se 
envió la señal. El programador no necesita estar enterado de esta tercera fase. Él escribe| un manejador de 
señales igual que cualquier otra función. El sistema operativo se encarga de lo detalles de invocar y 
terminar el manejador y administrar la pila. 
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En la fase de preparación hay varias llamadas al sistema que un proceso puede ejecutar en 
cualquier momento para modificar su respuesta a una señal. La más general de éstas es SIGACTION, que 
puede especificar que el proceso haga caso omiso de alguna señal, atrape alguna señal (sustituyendo la 
acción predeterminada por la ejecución de código de manejo de señales definido por el usuario dentro del 
proceso), o restaure la respuesta predeterminada a alguna señal. Otra llamada al sistema, 
SIGPROCMASK, puede bloquear una señal, causando que se ponga en cola y que sólo se efectúe la 
acción correspondiente cuando el proceso desbloquee esa señal en particular en algún momento posterior, 
si es que llega a hacerlo. Estas llamadas pueden efectuarse en cualquier momento, incluso desde el interior 
del código que maneja una señal atrapada. En MINIX la fase de preparación del procesamiento de señales 
corre totalmente por cuenta del administrador de memoria, ya que todas las estructuras de datos necesarias 
están en la parte de la tabla de procesos que le corresponde. Para cada proceso hay cierto número de 
variables sigset t, en las que cada señal posible está representada por un bit. Una de esas variables define 
un conjunto de señales a las que no se debe hacer caso, otra define un conjunto que debe atraparse, etc. 
Para cada proceso hay también un arreglo de estructuras sigaction, una para cada señal. Cada elemento de 
la estructura sigaction contiene una variable en la que se coloca la dirección de un manejador personaliza 
do para esa señal y una variable sigset t adicional para indicar las señales que se bloquearán mientras se 
está ejecutando ese manejador. El campo empleado para la dirección del manejador puede contener en vez 
de ella valores especiales que indiquen que la señal debe ignorarse o debe manejarse de la forma 
predefinida para esa señal. 

Cuando se genera una señal, pueden participar varias partes del sistema MINIX. La respuesta se 
inicia en el administrador de memoria, que determina cuál proceso debe recibir la señal utilizando las 
estructuras de datos que acabamos de mencionar. Si la señal debe atraparse, debe entregarse al proceso 
objetivo. Esto requiere guardar información acerca del estado del proceso, a fin de poder reanudar la 
ejecución normal. La información se almacena en la pila del proceso que recibió la señal, y debe 
verificarse que haya suficiente espacio en ella. El administrador de memoria se encarga de esta 
verificación, ya que le corresponde, y luego invoca la tarea del sistema en el kemel para que coloque la 
información en la pila. La tarea del sistema también manipula el contador de programa del proceso, de 
modo que el proceso pueda ejecutar el código del manejador. Cuando el manejador termina, se efectúa 
una llamada al sistema SIGRETURN. Por medio de esta llamada, tanto el administrador de memoria como 
el kemel participan en el restablecimiento del contexto de señales y los registros del proceso para que 
pueda reanudar su ejecución normal. Si la señal no se atrapa, se emprende la acción predeterminada, que 
puede implicar invocar el sistema de archivos para producir un vaciado de núcleo (escribir la imagen del 
proceso en un archivo que se puede examinar con un depurador), así como terminar el proceso, lo que 
requiere la participación del administrador de memoria, el sistema de archivos y el kemel. Por último, el 
administrador de memoria podría ordenar una o más repeticiones de estas acciones, ya que puede ser 
necesa rio entregar una misma señal a un grupo de procesos. 

Las señales que MINIX reconoce están definidas en /usr/include/signal.h, un archivo requerido 
por el estándar POSIX. Dichas señales se listan en la Fig. 4-41. Todas las señales requeridas por POSIX 
están definidas en MINIX, pero no todas ellas se reconocen actualmente. Por ejemplo, POSIX requiere 
varias señales relacionadas con el control de trabajos, la capacidad para poner en segundo 
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plano un programa en ejecución y traerlo otra vez a primer plano. MINIX no apoya el control de trabajos, 
pero los programas que podrían generar tales señales pueden trasladarse a MINIX. Se hará caso omiso de 
estas señales si se generan. MINIX también define algunas señales que no son de POSIX y algunos 
sinónimos de nombres de POSIX por compatibilidad con código fuente viejo. 


Señal 

Descripción 

Generada por 

SlGHUP 

Cuelga 

Llamada al sistema KILL 

SIGINT 

Interrumpe 

Kemel 

SIGQUIT 

Abandona 

Kemel 

SIGILL 

Instrucción no permitida 

Kemel (') 

SIGTRAP 

Trampa de rastreo 

Kernel (M) 

SIGABRT 

Terminación anormal 

Kemel 

SIGFPE 

Excepción de punto flotante 

Kemel (*) 

SlGKILL 

Kill (no puede atraparse ni ignorarse) 

Llamada al sistema KILL ^ 

SIGUSR1 

Señal definida por el usuario # 1 

No se reconoce 

SIGSEGV 

Violación de segmentación 

Kemel (*) 

SIGUSR2 

Señal definida por el usuario # 2 

No se reconoce 

SIQPIPE 

Escribe en un conducto sin nadie que lea 

Kemel 

SIGALRM 

Reloj de alarma, tiempo de espera 

Kemel 

SIGTERM 

Señal de terminación de software desde kfll 

Llamada al sistema KILL^ 

IsiGCHLD 

Proceso hijo terminado o detenido 

No se reconoce 

SIGCONT 

Continúa si está detenido 

No se reconoce 

SIGSTOP 

Señal de detenerse 

No se reconoce 

^ SIGTSTP 

Señal de detenerse interactiva 

No se reconoce 

| SIGTTIN 

Proceso de segundo piano desea leer 

No se reconoce 

SIGTTQU 

Proceso de segundo plano desea escribir 

No se reconoce 


Figura 4-41. Señales definidas por POSIX y MINIX. Las señales marcadas con (•) dependen del 
apoyo de hardware. Las señales marcadas con (M) no están definidas por POSIX. pero si por 
minix para fines de compatibilidad con programas viejos. Varios nombres y sinónimos obsoletos 
no aparecen en esta lista. 


Hay dos formas de generar señales: con la llamada al sistema KILL y desde el kemel. Las señales 
generadas por el kemel de MINIX siempre incluyen SIGINT, SIGQUIT y SIGALRM. Otras señales del 
kemel dependen del apoyo de hardware. Por ejemplo, los procesadores 8086 y 8088 no apoyan la 
detección de códigos de operación no válidos en las instrucciones, pero esta capacidad está disponible en 
el 286 y superiores, que atrapan un intento por ejecutar un código de operación no permitido. Este servicio 
es proporcionado por el hardware. El implementador del sistema operativo debe incluir código para 
generar una señal en respuesta a la trampa. Ya vimos en el capítulo! 
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que kemel/exception.c contiene código para hacer precisamente esto en varias condiciones diferentes. Así, 
puede generarse una señal SIGKILL como respuesta a una instrucción no permitida cuando MINIX se 
ejecuta en un procesador 286 o superior, pero esta señal nunca se verá cuando MINIX se ejecute en un 
8088. 

El hecho de que el hardware pueda atrapar cierta condición no implica que el implementador del 
sistema operativo pueda aprovechar plenamente esta capacidad. Por ejemplo, varios tipos de violaciones 
de la integridad de la memoria producen excepciones en todos los procesadores Intel a partir del 286. El 
código de kemel/exception.c traduce estas excepciones a señales SIGSEGV. Se generan excepciones 
distintas si se violan los límites del segmento de pila definido por hardware y de otros segmentos, ya que 
estos casos podrían requerir un tratamiento diferente. Sin embargo, dada la forma como MINIX utiliza la 
memoria, el hardware no puede detectar todos los errores que podrían ocurrir. El hardware define una base 
y un límite para cada segmento. La base del segmento de datos definido por el usuario es la misma que la 
base del segmento de datos de MINIX, pero el límite del segmento de datos definido por el hardware es 
más alto que el límite que MINIX hace respetar en software. En otras palabras, el hardware define el 
segmento de datos como la cantidad máxima de memoria que MINIX podría llegar a usar para los datos, si 
de alguna manera la pila pudiera encogerse hasta desaparecer. De forma similar, el hardware define la pila 
como la cantidad máxima de memoria que la pila de MINIX podría usar si el área de datos pudiera 
encogerse hasta desaparecer. Aunque el hardware puede detectar ciertas violaciones, no puede detectar la 
violación de pila más probable, el crecimiento de la pila al interior del área de datos, ya que en lo que a los 
registros y tablas de descriptores del hardware concierne el área de datos y el área de pila se traslapan. 

Sería concebible agregar código al kemel que verificara los registros de cada proceso cada vez que 
el proceso tiene oportunidad de ejecutarse, y generara una señal SIGSEGV en caso de detectar una 
violación de la integridad de las áreas de datos o de pila definidas por MINIX. Lo que no está claro es si 
valdría la pena; las trampas de hardware pueden detectar una violación de inmediato, pero una 
verificación en software tal vez no tendría oportunidad de hacer su trabajo sino hasta después de 
ejecutarse muchos miles de instrucciones adicionales, y a esas alturas probablemente sería muy poco lo 
que un manejador de señales podría hacer en un intento por recuperarse. 

Sea cual sea el origen de las señales, el administrador de memoria las procesa todas del mismo 
modo. Para cada proceso al cual se va a enviar una señal, se realiza una serie de verificaciones para 
determinar si la señal es factible. Un proceso puede enviar una señal a otro si es el superusuario o si su uid 
real o efectivo es igual al uid real o efectivo del proceso que recibe la señal. No obstante, hay varias 
condiciones que pueden impedir el envío de una señal. No es posible enviar una señal a un zombi, por 
ejemplo. No se puede enviar una señal a un proceso si éste invocó específicamente SIGACTION para 
ignorar la señal o SIGPROCMASK para bloquearla. Bloquear una señal no es lo mismo que ignorarla; la 
recepción de una señal bloqueada se recuerda, y la señal se entrega cuando el proceso destinatario quita el 
bloque, si es que alguna vez lo hace. Por último, si el espacio de pila del proceso destinatario de la señal 
no es suficiente, el proceso se cancela. 

Si se satisfacen todas las condiciones, se puede enviar la señal. Si el proceso no tomó medidas 
para atrapar la señal, no es necesario pasar información al proceso. En este caso el adminis- 
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trador de memoria ejecuta la acción predeterminada para la señal, que por lo regular es terminar el 
proceso, posiblemente produciendo también un vaciado de núcleo. En el caso de unas cuantas señales la 
acción predeterminada es hacer caso omiso de la señal. Las señales marcadas como "No se reconoce" en la 
Fig. 4-41 se definen porque POSIX así lo exige, pero MINIX las ignora. 

Atrapar una señal significa ejecutar el código de manejo de señal personalizado del proceso. La 
dirección de este código está almacenada en una estructura sigaction en la tabla de procesos. En el 
capítulo 2 vimos cómo el marco de pila de un proceso dentro de su entrada de la tabla de procesos recibe 
la información necesaria para iniciar el proceso cuando éste es interrumpido. Si se modifica el marco de 
pila del proceso al que se va a enviar una señal, puede lograrse que la próxima vez que se permita al 
proceso ejecutarse se ejecutará el manejador de señales. Mediante la modificación de la pila propia del 
proceso en el espacio de usuario, se puede lograr que cuando el manejador de señales termine se emita la 
llamada al sistema SIGRETURN. Esta llamada al sistema nunca es invocada por código escrito por el 
usuario; se ejecuta después de que el kemel coloca su dirección en la pila de tal manera que su dirección 
se convierte en la dirección de retomo que se saca de la pila cuando un manejador de señales termina. 
SIGRETURN restaura el marco de pila original del proceso al que se envió la señal, a fin que que pueda 
reanudar su ejecución en el punto en que fue interrumpido por la señal. 

Aunque la última etapa del envío de una señal corre por cuenta de la tarea del sistema, éste es un 
buen lugar para resumir cómo se hace, ya que es el administrador de memoria el que pasa al kemel los 
datos que se emplean. El atrapamiento de una señal requiere algo muy similar a la conmutación de 
contexto que ocurre cuando se suspende la ejecución de un proceso y se pone a ejecutan otro proceso, ya 
que cuando el manejador termine el proceso deberá poder continuar como si no hubiera sucedido nada. 
Sin embargo, sólo hay un lugar de la tabla de procesos donde se puede guardar el contenido de todos los 
registros de la CPU que se necesitan para restaurar el proceso a su estado original. La solución de este 
problema se muestra en la Fig. 4-42. La parte (a) de la figura es una vista simplificada de la pila de un 
proceso y de parte de su entrada en la tabla de procesos inmediatamente después de que se ha suspendido 
la ejecución de un proceso por una interrupción. En el momento de la suspensión el contenido de todos los 
registros de CPU se copia en la estructura de marco depila de la entrada de] proceso en la parte de la tabla 
de procesos que corresponde al kemel Ésta será la situación en el momento en que se genere una señal, ya 
que la ; señal es generada por un proceso o tarea diferente del destinatario de la señal. I 

Como preparación para manejar la señal, el marco de pila de la tabla de procesos se copia en la 
pila propia del proceso como una estructura sigcontext, a fin de conservarlo. Luego se coloca I una 
estructura sigfmme en la pila. Esta estructura contiene información que será utilizada por | SIGRETURN 
cuando el manejador termine, y también contiene la dirección del procedimiento de | biblioteca que invoca 
SIGRETURN misma, ret addrí, y otra dirección de retomo, ret addr2, que es' la dirección donde se 
reanudará la ejecución del programa interrumpido. Sin embargo, como habremos de ver, la segunda 
dirección no se usa durante la ejecución normal. 

Aunque el programador escribe el manejador como un procedimiento ordinario, no se invoca con 
una instrucción CALL. El campo de apuntad r de ins trucción (contador de programa) del marco de pila en 
la tabla de procesos se altera de modo que haga que el manejador de señales comience a ejecutarse cuando 
restan coloque otra vez en ejecución el proceso que recibió la señal. La Fig. 4-42(b) 



SEC. 4.7 


GENERALIDADES DE ADMINISTRACIÓN DE MEMORIA EN MINIX 


377 





Ral ador 
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Var locales 
(proceso) 

Var locales 
(proceso) 


Marco de pila 
(regs. CPU) 
(original) 


Ret addr 2 
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sigframe 

Ret addr 1 

Var. locales 
(manejador) 
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depila (regs. 
CPU) 
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Marco de pila 
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Marco de pila 
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(original) 
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(sigretom) 
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(regs. CPU) 


Marco de pila 

(modificado. 


(regs. CPU) 

ip = maro 


(original) 

jador) 




Antes Mandador 

ejecutándose 


Sigreturn 

ejecutándose 


Vuelta a la 
normalidad 


(a) <b) (c) 


«J) 


Pía 


Tabla 

de procesos 


Figura 4-42. La pila de un proceso (arriba) y su marco de pila en la tabla de procesos (abajo) 
en las diferentes fases de manejo de una señal, (a) Estado cuando se suspende la ejecución del 
proceso, (b) Estado al iniciarse la ejecución del manejador (c) Estado mientras se está ejecutando 
SIGRETI'RN. (d) Estado después de que termina de ejecutarse SIGRETURN. 


también muestra la situación después de que se ha completado esta preparación y durante la ejecución del 
manejador de señales. Recuérdese que el manejador de señales es un procedimiento ordinario, así que 
cuando termina se remueve de la pila ret addrí y se ejecuta SIGRETURN. 

La parte (c) muestra la situación mi entras se está ejecutando SIGRETURN. El resto de la 
estructura sigframe consta ahora de las variables locales de SIGRETURN. Parte de la acción de 
SIGRETURN es ajustar su propio apuntador de pila de modo que, si llegara a terminar como una función 
ordinaria, utilizaría ret addr2 como dirección de retomo. Sin embargo, SIGRETURN realmente no ter mi na 
de este modo; term in a igual que otras llamadas al sistema, permitiendo al planificador del kemel decidir 
cuál proceso habrá de reiniciar. Tarde o temprano, el proceso que recibió la señal será replanificado y 
reiniciará en esta dirección, porque la dirección también está en el marco de pila original del proceso. La 
razón por la que esta dirección está en la pila es que un usuario podría querer rastrear un programa 
empleando un depurador, y esto engaña al depurador 
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haciéndolo que efectúe una interpretación razonable de la pila mi entras se está rastreando un manejador de 
señales. En cada fase, la pila semeja la de un proceso ordinario, con variables locales encima de una 
dirección de retomo. 

La verdadera labor de SIGRETURN es restaurar las cosas al estado en que estaban antes de que se 
recibiera la señal, y realizar aseo. Lo más importante es que el marco de pila en la tabla de procesos se 
restaura a su estado original, empleando la copia que se guardó en la pila del proceso que recibió la señal. 
Cuando SIGRETURN termina, la situación será como en la Fig. 4-42(d), que muestra al proceso 
esperando volver a entrar en ejecución en el mismo estado en el que estaba cuando fue interrumpido. 

En el caso de la mayor parte de las señales, la acción predeterminada consiste en ter mi nar el 
proceso al que se envía la señal. El administrador de memoria se encarga de esto para cualquier señal que 
no es ignorada por omisión, siempre que el proceso receptor no haya sido habilitado para manejar, 
bloquear o ignorar la señal. Si el padre del proceso que es terminado por la señal está esperándolo, el 
proceso terminado se asea y retira de la tabla de procesos. Si el padre no está esperando, el proceso 
terminado se convierte en zombi. En el caso de ciertos números de señal (p. ej., SIGQUIT), el 
administrador de memoria también escribe un vaciado de núcleo del proceso en el directorio actual. 

Puede suceder fácilmente que se envíe una señal a un proceso que actualmente está bloqueado 
esperando un READ en una ter mi nal para la cual no hay entradas disponibles. Si el proceso no especificó 
que la señal debe atraparse, simplemente se ter mi na de la forma acostumbrada. En cambio, si la señal es 
atrapada, surge la cuestión de qué debe hacerse una vez que se ha procesado la interrupción de la señal. 
¿El proceso debe seguir esperando o debe continuar con la siguiente instrucción? 

Lo que MINIX hace es esto: la llamada al sistema se termina de tal manera que devuelve el,; código de 
error EINTR, con lo que el proceso puede darse cuenta de que la llamada fúe interrum-1 pida por una 
señal. No es del todo trivial determinar si un proceso al que se envió una señal estaba bloqueado en una 
llamada al sistema. El administrador de memoria debe interrogar al sistema de archivos para verificarlo. 

POSIX sugiere, pero no exige, este comportamiento, que también permite a un READ devolver el 
número de bytes leídos hasta el momento en que se recibió la señal. La devolución de EINTR hace posible 
establecer una alarma y atrapar SIGALRM. Ésta es una forma sencilla de implementar un tiempo de 
espera, por ejemplo para terminar login y colgar una línea de módem si un usuario! no responde dentro de 
cierto periodo. Se puede usar la tarea de reloj síncrona para hacer lo núsmo; con menos gasto extra, pero 
dicha tarea es una invención de MINIX y no es an portátil como el| empleo de señales. Además, esa tarea 
sólo está disponible para los procesos servidores, noparq los procesos de usuario ordinarios. 

4.7.8 Otras llamadas al sistema 

El administrador de memoria maneja otras pocas llamadas al sistema sencillas. Las fimcionesj biblioteca 
getuid y geteuid invocan la llamada al sistema GETUID, que devuelve ambos valórese su mensaje de 
retomo. De forma análoga, la llamada al sistema GETGID devuelve los valores i y efectivo que utilizan 
las funciones getgid y getegid. GETPID funciona del mismo modo ] 
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devolver tanto el identificador del proceso como el identificador de su padre, y SETUID y SETGID 
pueden establecer los valores tanto real como efectivo en una llamada. Hay otras dos llamadas al sistema 
en este grupo, GETPGRP y SETSID. La primera devuelve el identificador del gurpo de procesos, y la 
segunda le asigna el valor del pid actual. Estas siete llamadas son las llamadas al sistema más sencillas de 
MINIX. 

El administrador de memoria también maneja las llamadas al sistema PTRACE y REBOOT. La 
primera apoya la depuración de los programas. La segunda afecta muchos aspectos del sistema; resulta 
apropiado colocarla en el administrador de memoria porque su primera acción es enviar señales para 
ter mi n a r todos los procesos con excepción de init. Luego, REBOOT recurre al sistema de archivos y a la 
tarea del sistema para completar su trabajo. 

4.8 IMPLEMENTACIÓN DE LA ADMINISTRACIÓN DE MEMORIA EN MINIX 

Ahora que sabemos en términos generales cómo funciona el administrador de memoria, pasemos al código 
mismo. El administrador de memoria está escrito totalmente en C, es fácil de entender y contiene 
cantidades sustanciales de comentarios en el código mismo, así que nuestro tratamiento de casi todas sus 
partes no tiene por qué ser largo ni rebuscado. Primero examinaremos brevemente los archivos de 
cabecera, luego el programa principal y por último los archivos para los diversos grupos de llamadas al 
sistema que describimos anteriormente. 

4.8.1 Los archivos de cabecera y estructuras de datos 

Varios archivos de cabecera en el directorio fuente del administrador de memoria tienen los mismos 
nombres que otros archivos en el directorio del kemel, y veremos otra vez estos nombres en el sistema de 
archivos. Los archivos correspondientes tienen funciones similares en sus propios contextos. Tal 
estructura paralela tiene como propósito facilitar el entendimiento de la organización de todo el sistema 
MINIX. El administrador de memoria tiene además varias cabeceras con nombres únicos. Al igual que en 
otras partes del sistema, se reserva espacio para las variables globales cuando se compila la versión de 
table.c del administrador de memoria. En esta sección estudiaremos todos los archivos de cabecera, 
además de table.c. 

Al igual que en las otras partes principales de MINIX, el administrador de memoria tiene un 
archivo de cabecera maestro, mm.h (línea 15800). Éste se incluye en todas las compilaciones, y a su vez 
incluye todos los archivos de cabecera en el nivel de sistema de /usr/include y sus subdirectorios, mismos 
que necesitan todos los módulos objeto. La mayor parte de los archivos que se incluyen en kemel/kemel.h 
también se incluyen aquí. Además, el administrador de memoria necesita las definiciones contenidas en 
include/fcntl.h e include/unistd.h. También se incluyen las versiones de const.h, type.h, proto.h y glo.h 
propias del administrador de memoria. 

Const.h (línea 15900) define algunas constantes utilizadas por el administrador de memoria, sobre 
todo cuando se compila para máquinas de 16 bits. La línea 


#define printf printk 
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está contenida aquí con objeto de que las llamadas a printf se compilen como llamadas a la función printf. 
La función es similar a la que vimos en el kemel, y se define por una razón pareeii para que el 
administrador de memoria pueda exhibir mensajes de error y depuración sin pe ayuda al sistema de 
archivos. 

Type.h no se utiliza actualmente y existe en forma de esqueleto para que los archivos ( 
administrador de memoria tengan la misma organización que las demás partes de MINIX. Proh (línea 
16100) reúne en un solo lugar prototipos de funciones que se requieren a todo lo largo del administrador 
de memoria. 

Las variables globales del administrador de memoria se declaran en glo.h (línea 16200). usa aquí 
el mismo truco que se usó en el kemel con EXTERN, a saber, EXTERN normalmente una macro que se 
expande a extern, excepto en el archivo table.c. Ahí, se convierte en la cade nula a fin de poder reservar 
espacio para las variables declaradas como EXTERN. 

La primera de estas variables, mp, es un apuntador a ua estructura mproc, la parte de la tat de 
procesos del administrador de memoria correspondiente al proceso cuya llamada al sistema está 
procesando. La segunda variable, dont reply (no contestar), se inicializa en FALSE cuaní llega una 
solicitud nueva pero se le puede asignar TRUE durante la llamada si se descubre que i debe enviarse 
ningún mensaje de respuesta. Por ejemplo, no se envían respuestas cuando i EXEC tiene éxito. La tercera 
variable, procs in use, lleva la cuenta de cuántas ranuras de proce ¡ se están usando actualmente, lo que 
facilita determinar si una llamada FORK es factible. 

Los buffers de mensajes mmin y mmout son para los mensajes de solicitud y de respuesta 
Respectivamente. Who es el índice del proceso en curso; está relacionado con mp mediante 

mp = &mproc[who]; 

Cuando llega un mensaje, se extrae de él el número de llamada al sistema y se coloca en mm_ca¡ Las tres 
variables errcode, resultl y res_ptr sirven para contener valores que se devuelve Al invocador en el 
mensaje de respuesta. La más importante de estas variables es err code, a 1 que se asigna OK si la 
llamada se lleva a cabo sin error. Las últimas dos variables se usan si surge Un problema. MINIX escribe 
una imagen de un proceso en un archivo de núcleo cuando el proceso Termina anormalmente. Corename 
define el nombre que tendrá este archivo, y core sset es u mapa de bits que define cuáles señales deben 
producir vaciados de núcleo. 

La parte de la tabla de procesos que corresponde al administrador de memoria está en el siguiente 
archivo, mproc. h (línea 16300). La mayor parte de los campos están descritos con claridad por su 
comentarios. Varios campos tienen que ver con el manejo de señales. Mp ignore, mpcatch mp sigmask, 
mp_sigmask2 y mp sigpending son mapas de bits en los que cada bit representa una de las señales que se 
pueden enviar a un proceso. El tipo sigset t es un entero de 32 bits, así que MINIX podría reconocer 
fácilmente hasta 32 señales, aunque actualmente sólo están definidas 16 correspondiendo a la señal 1 el bit 
menos significativo (el de la extrema derecha). En cualquier caso POSIX requiere funciones estándar para 
agregar o eliminar miembros de los conjuntos de señal? representados por estos mapas de bits, así que 
todas las manipulaciones necesarias pueden efectuara sin que el programador esté consciente de estos 
detalles. El arreglo mp sigact es importante pan manejar señales. Hay un elemento para cada tipo de 
señal, y cada elemento es una estructura sigactim (definida en include/signal.h). Cada estructura sigaction 
consta de tres campos: 
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1. El campo sahandler define si la señal debe manejarse de la forma predeterminada, ignorarse o 
manejarse con un manejador especial. 

2. El campo sa mask es un sigset t que define cuáles señales deben bloquearse cuando la señal 
esté siendo manejada por un manejador personalizado. 

3. El campo sa flags es un conjunto de banderas que se aplican a la señal. 

Este arreglo hace posible una gran flexibilidad en el manejo de señales. 

El campo mpflags sirve para contener una colección diversa de bits, como se indica al final Del archivo. 
Este campo es un entero sin signo, de 16 bits en las CPU antiguas o de 32 bits en una 386 o superior. Hay 
mucho espacio para expansión aquí, incluso en una 8088, ya que sólo se usan nueve bits. 

El último campo de la tabla de procesos es mp_procargs. Cuando se inicia un proceso nuevo, se 
construye una pila como la que se muestra en la Fig. 4-39, y se almacena aquí un apuntador al principio 
del arreglo argv del nuevo proceso. El comando ps usa este apuntador. Por ejemplo, en el caso que se 
ilustra en la Fig. 4-39, se guardaría aquí el valor 8164, con lo que se podría exhibir la línea de comandos 
Is -I f.c g.c 

si se ejecuta mientras está activo el comando Is. 

El siguiente archivo es param.h (línea 16400), que contiene macros para muchos de los parámetros de 
llamadas al sistema contenidos en el mensaje de solicitud. Este archivo también contiene cuatro macros 
para campos del mensaje de respuesta. Cuando aparece el enunciado 
k = pid; 

en cualquier archivo en el que se ha incluido param.h, el preprocesador lo convierte en 
k=mm_in.ml_il; 

antes de alimentarlo al compilador propiamente dicho. 

Antes de continuar con el código ejecutable, examinemos table.c (línea 16500). Su compilación reserva 
espacio para las diversas variables y estructuras EXTERN que hemos visto en glo.h y mproc.h. El 
enunciado 

#define_TABLE 

hace que EXTERN se convierta en la cadena nula. Este es el mismo mecanismo que vimos en el código 
del kemel. 

La otra característica importante de table.c es el arreglo callvec (línea 16515). Cuando llega un 
mensaje de solicitud, se extrae de él el número de llamada al sistema y se usa como índice para encontrar 
en call vec el procedimiento que lleva a cabo esa llamada al sistema. Todos los números de llamada al 
sistema que no son válidos invocan a no sys, que se li mi ta a devolver un código de error. Adviértase que 
aunque se usa la macro JPROTOTYPE para definir call vec, no se trata de la declaración de un prototipo; 
es Ja definición de un arreglo inicializado. No obstante, call vec es 
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un arreglo de funciones, y el uso de PROTOTYPE es la forma más fácil de hacer esto que es compatible 
tanto con el C clásico (Kemighan & Ritchie) como con Standard C. 

4.8.2 El programa principal 

El administrador de memoria (MM) se compila y enlaza de forma independiente respecto al kemel y el 
sistema de archivos; en consecuencia, tiene su propio programa principal, que se inicia una vez que el 
kemel ha terminado de inicializarse a sí mismo. El programa principal está en main.c, en la línea 16627. 
Después de efectuar su propia inicialización llamando a mminit, el administrador de memoria ingresa en 
su ciclo en la línea 16636. En este ciclo, el MM invoca getwork para esperar la llegada de un mensaje de 
solicitud, luego invoca uno de sus procedimientos do XXX a través de la tabla call vec para atender la 
solicitud, y por último envía una respuesta, si es necesario. Esta construcción ya debe ser conocida a estas 
alturas: es la misma que emplean las tareas de E/S. 

Los procedimientos get work (línea 16663) y reply (línea 16676) se encargan de la recepción y el 
envío, respectivamente. 

El último procedimiento de este archivo es mm init, que inicializa el administrador de memoria y 
que no se usa después de que el sistema ha entrado en fúncionamiento. La llamada a sys getmap en la 
línea 16730 obtiene información acerca del uso de memoria del kemel. El ciclo de las líneas 16734 a 
16741 inicializa todas las entradas de la tabla de procesos para las tareas y los servidores, y las siguientes 
l ín eas preparan la entrada de init en la tabla de procesos. En la línea 16749 el MM espera que el sistema 
de archivos (FS) le envíe un mensaje. Como se mencionó cuando hablamos del manejo de bloqueos en 
MINIX, éste es el único momento en que el ES envía un mensaje de solicitud al administrador de 
memoria. El mensaje indica cuánta memoria se está usando para el disco en RAM. La llamada a meminit 
en la línea 16755 inicializa la lista de agujeros invocando la tarea del sistema. Después de esto ya puede 
comenzar la administración normal de la memoria. Esta llamada también asigna valores a las variables 
total clicks y ffee clicks, completando la información que mm i ni t necesita para exhibir un mensaje 
indicando la memoria total, el uso de memoria por el kemel, el tamaño del disco en RAM y la memoria 
libre. Después de exhibir el mensaje se envía una respuesta al FS (línea 16764) para permitirle que 
continúe. Por último, se proporciona a la tarea de memoria la dirección de la parte de la tabla de procesos 
que corresponde al MM, a fin de que el comando ps cuente con esa información. 

4.8.3 Implementación de FORK, EXIT y WAIT 

Las llamadas al sistema FORK, EXIT y WAIT se implementan con los procedimientos dofork, 
dommexitydowait que están en el archivo forkexit.c. El procedimiento do fork (línea 16832) sigue los 
pasos que se muestran en la Pig. 4-37. Observe que la segunda llamada a procsmuse (línea 16847) 
reserva unas cuantas ranuras al final de la tabla de procesos para el superusuario. Al calcular cuánta 
memoria necesita el hyo, se induye e\ espacio entte los segmentos de datos y de pila, pero no se incluye el 
segmento de texto. O bien se comparte el texto del padre, o, si el 
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proceso tiene espacio 1 y D común, su segmento de texto tiene longitud cero. Después de efectuar el 
cálculo, se invoca allocmem para obtener la memoria. Si esta asignación tiene éxito, las direcciones base 
del hijo y del padre se convierten de clics a bytes absolutos, y se invoca sys copy para enviar un mensaje 
a la tarea del sistema, la cual se encargará del copiado. 

Ahora se encuentra una ranura en la tabla de procesos. La prueba previa en la que intervino 
procs in use garantiza que habrá una ranura. Una vez localizada ésta, se llena copiando primero la ranura 
del padre ahí y luego actualizando los campos mp_parent, mpflags, mp seg, mpexitstatus y 
mp sigstatus. Algunos de estos campos requieren un manejo especial. El bit TRACED del campo 
mp flags se pone en cero, ya que un hijo no hereda la situación de rastreo. El campo mp seg es un arreglo 
que contiene elementos para los segmentos de texto, datos y pila, y se deja que la porción de texto siga 
apuntando al segmento de texto del padre si las banderas indican que se trata de un programa con I y D 
separado que puede compartir el texto. 

El siguiente paso es asignar un pid al hijo. La variable next_pid contiene el siguiente pid por 
asignar. Sin embargo, es concebible que ocurra el siguiente problema. Después de asignarse, digamos, el 
pid 20 a un proceso de muy larga vida, podrían crearse y destruirse 30 000 procesos más, y next_pid 
podría regresar otra vez a 20. La asignación de un pid que todavía se está usando sería un desastre 
(supongamos que alguien trata de enviar una señal al proceso 20), así que efectuamos una búsqueda en 
toda la tabla de procesos para aseguramos de que el pid que se va a asignar no está todavía en uso. 

Las llamadas a sys fork y tell fs informan al kemel y al sistema de archivos, respectivamente, que 
se ha creado un proceso nuevo, a fin de que puedan actualizar sus tablas de procesos. (Todos los 
procedimientos que comienzan con sys_ son rutinas de biblioteca que envían un mensaje a la tarea del 
sistema en el kemel para solicitar uno de los servicios de la Fig. 3-50). La creación y destrucción de 
procesos siempre son iniciadas por el administrador de memoria y luego se propagan al kemel y al sistema 
de archivos una vez que se completan. 

El mensaje de respuesta al hijo se envía explícitamente al final de do fork. La respuesta al padre, 
que contiene el pid del hijo, es enviada por el ciclo de main, como respuesta normal a una solicitud. 

La siguiente llamada al sistema que el administrador de memoria maneja es EXIT. El 
procedimiento dommexit (línea 16912) acepta la llamada, pero casi todo el trabajo corre por cuenta de 
la llamada a mmexit, unas cuantas líneas más abajo. La razón por la que el trabajo se divide de esta 
forma es que mm exit también se invoca para encargarse de los procesos que han sido terminados por una 
señal. El trabajo es el mismo, pero los parámetros son diferentes, así que resulta conveniente dividir las 
cosas de esta manera. 

Lo primero que mm exit hace es detener el temporizador, si el proceso tiene uno en 
fúncionamiento. A continuación, se notifica al kemel y al sistema de archivos que el proceso ya no es 
ejecutable (líneas 16949 y 16950). La llamada al procedimiento de biblioteca sys xit envía un mensaje a 
la tarea del sistema diciéndole que marque el proceso como no ejecutable, a fin de que yano se le 
calendarice. Acto seguido, se libera la memoria. Una llamada Sifind share determina si el segmento de 
texto está siendo compartido por otro proceso y, si no es así, el segmento de texto ; se libera con una 
llamada Sifreemem. Esto va seguido de otra llamada al mismo procedimiento para liberar los datos y la 
pila. No vale la pena decidir si toda la memoria podría liberarse con una 
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sola llamada afreemem o no. Si el padre está esperando, se invoca cleanup para liberar la ranura de la 
tabla de procesos; si no, el proceso se convierte en un zombi, lo cual se indica con el bit HANGING de la 
palabra mpflags. Sea que el proceso se elimine por completo o se convierta en zombi, la acción final de 
mmexit es recorrer la tabla de procesos en busca de los hijos del proceso que acaba de terminarse (líneas 
16975 a 16982). Si se encuentra algún hijo, se le deshe- reda, convirtiéndolo en hijo de init. Si init está 
esperando y un hijo está pendiente, se invoca cleanup para ese hijo. Esto resuelve las situaciones como las 
de la Fig. 4-43(a). En esta figuravemos que el proceso 12 está a punto de salir, y que su padre, 7, está 
esperándolo. Se invocará cleanup para deshacerse de 12, con lo cual 52 y 53 se convierten en hijos de init, 
como se muestra en la Fig. 4-43(b). Ahora tenemos una situación en la que 53, que ya salió, es el hijo de 
un proceso que está ejecutando WAIT; por tanto, también puede someterse a aseo con cleanup. 



Cuando el proceso padre ejecuta WAIT o WAITPID, el control pasa al procedimiento dowaitpid en la 
línea 16992. Los parámetros que proporcionan las dos llamadas son diferentes, y las acciones esperadas 
también son diferentes, pero la preparación efectuada en las líneas 17009 a 17011 establece variables 
intemas de modo que do waitpid pueda realizar las acciones de cualquiera de las dos llamadas. El ciclo de 
las líneas 17019 a 17041 examina toda la tabla de procesos para ver si el proceso tiene hijos y, de ser así, 
verifica si cualesquiera de ellos son zombis que puedan someterse a aseo. Si se encuentra un zombi (línea 
17026), se somete a aseo y doYvaitpid regresa. La bandera dontreply se enciende poique la respuesta al 
padre se envía desde el interior de cleanup, no desde el ciclo de main. Si se encuentra un hijo rastreado, se 
envía una respuesta indicando que el proceso está detenido, y do waitpid regresa. También se enciende 
dont reply para evitar que main envíe una segunda respuesta. 

Si el proceso que está ejecutando WAIT no tiene hijos, simplemente regresa con un error (línea 
17053). Si el proceso tiene hijos, pero ninguno de ellos es un zombi o está siendo rastreado, se efectúa una 
prueba para ver si do waitpid se invocó con un bit encendido indicando que el padre no quería esperar. Si 
no fue así (el caso normal), se enciende un bit en la línea 17047 para indicar que el padre está esperando, y 
éste se suspende hasta que el hijo termina. 

Cuando un proceso ya salió y su padre lo está esperando, sea cual sea el orden en que ocurran ¡ 
estos sucesos, se invoca el procedimiento cleanup (línea 17061) para administrar la extremaim- 
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ción. No hay mucho que pueda hacerse a estas alturas. Se despierta al padre de su llamada WAIT o 
WAITPID y se le proporciona el pid del hijo que terminó, así como su situación de salida y de señales. El 
sistema de archivos ya liberó la memoria del hijo, y el kemel ya suspendió su planificación, así que lo 
único que tiene que hacer ahora el kemel es liberar la ranura del hijo en la tabla de procesos. 

4.8.4 Implementación de EXEC 

El código para EXEC se ajusta a la descripción resumida de la Fig. 4-38 y está contenido en el 
procedimiento doexec (línea 17140). Después de efectuar unas cuantas verificaciones de validez 
sencillas, el administrador de memoria obtiene del espacio de usuario el nombre del archivo por ejecutar. 
En la línea 17172 el MM envía un mensaje especial al sistema de archivos para cambiar al directorio de 
usuario, con objeto de que la trayectoria que acaba de obtenerse se interprete en relación con el directorio 
de trabajo del usuario, no al del MM. 

Si el archivo está presente y es ejecutable, el administrador de memoria lee la cabecera para 
extraer los tamaños de los segmentos. A continuación, el MM obtiene la pila del espacio de usuario (líneas 
17188 y 17189), verifica si el nuevo proceso puede compartir el texto con un proceso que ya se está 
ejecutando (línea 17196), asigna memoria para la nueva imagen (línea 17199), repara los apuntadores 
[véanse las diferencias entre la Fig. 4-3 9(b) y (c)] y lee del disco el segmento de texto (si es necesario) y el 
segmento de datos (líneas 17221 a 17226). Por último, el MM procesa los bits setuid y setgid, actualiza la 
entrada de la tabla de procesos y le informa al kemel que ya terminó, a fin de que el proceso pueda 
calendarizarse otra vez. 

Aunque el control de todos los pasos está en do exec, muchos de los detalles corren por cuenta de 
procedimientos subsidiarios dentro de exec.c. Readheader (línea 17272), por ejemplo, no sólo lee la 
cabecera y devuelve los tamaños de segmento, sino también verifica que el archivo sea un ejecutable 
válido de MINIX para el mismo tipo de CPU para el cual está compilado el sistema operativo. Esto se 
hace mediante una compilación condicional de la prueba apropiada en el momento en que se compila el 
administrador de memoria (líneas 17322 a 17327). Read header también verifica que todos los segmentos 
quepan en el espacio de direcciones virtual. 

El procedimiento newmem (línea 17366) comprueba que haya suficiente memoria disponible 
para la nueva imagen de memoria. Este procedimiento busca un agujero con el tamaño suficientes te para 
los datos y la pila únicamente si el texto está siendo compartido; en caso contrario, busca un agujero único 
en el que puedan caber el texto, los datos y la pila combinados. Una posible mejora aquí sería buscar dos 
agujeros distintos, uno para el texto y otro para los datos y la pila, ya que no hay necesidad de que estas 
áreas sean contiguas. En versiones anteriores de MINIX esto era obligatorio. Si se encuentra suficiente 
memoria, se libera la memoria anterior y se adquiere la nueva. Si no hay suficiente memoria disponible, la 
llamada EXEC falla. Una vez que se ha asignado la nueva memoria, new mem actualiza el mapa de 
memoria (en mp seg) e informa de ello al kemel invocando el procedimiento de biblioteca sysnewmap. 

El resto de new mem se ocupa de poner en ceros el segmento bss, el espacio y el segmento de 
pila. (El segmento bss es la parte del segmento de datos que contiene todas las variables globales no 
inicializadas.) Muchos compiladores generan código explícito para poner en ceros el 
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segmento bss, pero al hacer esto aquí se logra que MINIX funcione incluso con compiladores que no lo 
hacen. El espacio entre los segmentos de datos y de pila también se pone en ceros, de modo que cuando 
BRK extienda el segmento de datos la memoria recién adquirida contenga ceros. Esto no sólo es cómodo 
para el programador, quien puede estar seguro de que las nuevas variables tendrán un valor inicial de cero, 
también es una característica de seguridad en un sistema operativo multiusuario, en el que un proceso que 
utilizó previamente esta memoria podría haber estado usando datos que otros procesos no deben ver. 

El siguiente procedimiento es patch_ptr (línea 17465), que se encarga de reubicar los apuntadores 
de la Fig. 4-39(b) a la forma de la Fig. 4-39(c). El trabajo es sencillo: se examina la pila hasta encontrar 
todos los apuntadores y se suma la dirección base a cada uno. 

El procedimiento load seg (línea 17498) se invoca una o dos veces en cada EXEC, posiblemente 
para cargar el segmento de texto y siempre para cargar el segmento de datos. En lugar de limitarse a leer el 
archivo bloque por bloque y luego copiar los bloques al usuario, se emplea un truco para permitir que el 
sistema de archivos cargue todo el segmento directamente en el espacio de usuario. En efecto, la llamada 
es descodificada por el sistema de archivos de una forma un tanto especial con objeto de que parezca ser 
una lectura del segmento completo por parte del proceso de usuario mismo. Sólo unas cuantas líneas al 
principio de la rutina de lectura del sistema de archivos saben que aquí está ocurriendo algo sospechoso. 
Esta maniobra agiliza considerablemente la carga. 

El procedimiento final de exec.c esfind share (línea 17535), el cual busca un proceso capaz de 
compartir texto comparando el nodo-i, el dispositivo y los tiempos de modificación del archivo por 
ejecutar con los de los procesos existentes. Se trata de una búsqueda directa de los campos apropiados de 
mproc. Desde luego, no debe incluirse en la búsqueda el proceso a nombre del cual se está efectuando. 

4.8.5 Implementación de BRK 

Como acabamos de ver, el modelo de memoria que MINIX emplea es muy sencillo: cada proceso recibe 
una sola asignación de memoria contigua para sus datos y su pila cuando se crea. El proceso nunca se 
cambia de lugar en la memoria, nunca se intercambia a disco, nunca crece y nunca se encoge. Lo único 
que puede suceder es que el segmento de datos reduzca el espacio desde su extremo inferior y que la pila 
lo reduzca desde su extremo superior. En estas circunstancias, la implementación de la llamada BRK en 
break.c es muy fácil; consiste en verificar que los nuevos tamaños sean factibles y actualizar después las 
tablas de modo que los reflejen. 

El procedimiento de nivel más alto es dobrk (línea 17628), pero la mayor parte del trabajo se 
efectúa en adjust (línea 17661). Este último verifica si los segmentos de datos y de pilaban chocado. Si así 
fúe, no es posible llevar a cabo el BRK, pero el proceso no se term in a de inmediato. Un factor de 
seguridad, SAFETY BYTES, se agrega a la parte superior del segmento de datos antes de realizar la 
prueba, de modo que (con suerte) la decisión de que la pila ha crecido demasiado puede tomarse mientras 
todavía hay suficiente espacio en la pila para que el proceso continúe durante un tiempo corto. El proceso 
recupera el control (recibiendo un mensaje de error) para que pueda imprimir los mensajes apropiados y 
después termine de forma ordenada. 
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Observe que SAFETYJBYTES se define empleando una instrucción #define a la mitad del 
procedimiento (línea 17693). Este uso es poco común; normalmente tales definiciones aparecen al 
principio de los archivos, o en archivos de cabecera aparte. El comentario correspondiente revela que al 
programador se le hizo difícil decidir qué tamaño debía tener el factor de seguridad. No hay duda de que 
la definición se realizó de esta manera con objeto de atraer la atención y, tal vez, estimular experimentos 
adicionales. 

La base del segmento de datos es constante, así que si adjust se ve obligado a ajustar el segmento 
de datos lo único que hace es actualizar el campo de longitud. La pila crece hacia abajo desde un extremo 
fijo, así que si adjust también se da cuenta de que el apuntador de la pila, que recibe como parámetro, ha 
crecido más allá del segmento de pila (a una dirección situada más abajo), actualiza tanto el origen como 
la longitud. 

El último procedimiento de este archivo, si7.e_ok (línea 17736) efectúa una prueba para 
determinar si los tamaños de los segmentos caben dentro del espacio de direcciones, tanto en clics como 
en bytes. Se conservó en el listado el código condicional para máquinas de 16 bits con el propósito de 
mostrar por qué se escribió en forma de fúnción individual. No tendría mucho caso tener este código como 
fúnción individual para MINIX de 32 bits. Este procedimiento se invoca en sólo dos lugares, y la 
sustitución de la línea 17765 en lugar de las llamadas produciría código más compacto, ya que las 
llamadas pasan varios argumentos que no se usan en la implementación de 32 bits. 

4.8.6 Implementación del manejo de señales 

Hay ocho llamadas al sistema relacionadas con señales, las cuales se resumen en la Fig. 4-44. Estas 
llamadas, así como las señales mismas, se procesan en el archivo signal.c. Este archivo maneja también 
una llamada al sistema adicional, REBOOT, ya que emplea señales para terminar todos los procesos. 


Llamada al alaterna 

Propósito 

SlGACTlON 

Modifica la respuesta a una señal futura 

SIGPROCMASK 

Camóia el conjunto de señales bloqueadas 

NU. 

1 Envía una señal a otro proceso 

ALARM 

r Se envía a sí misma la llamada ALRM después de un retardo 

MUSE 

1 Se suspende a sí misma basta una señal futura 

SIGSUSPEND 

Cambia el conjunto de señales bloqueadas, luego PAUSE 

SGPENOWG 

Examina el conjunto de señales pendientes (bloqueadas) 

SlGRETURN 

Hace aseo al terminar el manejador de señales 


Figura 4-44. Llamadas al sistema relacionadas con señales. 
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La llamada SIGACTION apoya las funciones sigaction y signal, que permiten a un proceso alterar 
la forma como responde a las señales. POSIX exige sigaction y es la llamada preferida en casi todos los 
casos, pero Standard C requiere la función de biblioteca signal, y los programas que deben ser trasladables 
a sistemas no POSIX deben escribirse usándola. El código de dosigaction (línea 17845) comienza con 
verificaciones de la validez del número de señal y de que la llamada no es un intento por modificar la 
respuesta a una señal SIGKILL (líneas 17851 y 17852). (No se permite ignorar, atrapar o bloquear 
SIGKILL. SIGKILL es el mecanismo definitivo mediante el cual un usuario puede controlar sus procesos 
y un administrador del sistema puede controlar a sus usuarios.) SIGACTION se invoca con apuntadores a 
una estructura sigaction, sig osa, que recibe los antiguos atributos de señal que estaban vigentes antes de 
la llamada, y a una estructura del mismo tipo, signsa, que contiene un nuevo conjunto de atributos. 

El primer paso es invocar la tarea del sistema para que copie los atributos actuales en la estructura 
a la que sig osa apunta. Se puede invocar SIGACTION con un apuntador NULL en sig nsa si lo que se 
desea es examinar los antiguos atributos de señal sin modificarlos. En este caso do sigaction regresa de 
inmediato (línea 17860). Si sig nsa no es NULL, la estructura que define la nueva forma de reaccionar a 
las señales se copia en el espacio del administrador de memoria. El código de las líneas 17867 a 17877 
modifica los mapas de bits mpcatch, mpjgnore y mp sigpending de modo que reflejen la nueva acción, 
que puede ser ignorar la señal, usar el manejador predeterminado o atrapar la señal. Se emplean las 
funciones de biblioteca sigaddsety sigdelset, aunque las acciones son operaciones de manipulación de bit 
directas que podrían haberse implementado con macros sencillas. Sin embargo, el estándar POSIX 
requiere estas funciones a fin de asegurar que los programas que las usen puedan trasladarse fácilmente, 
incluso a sistemas en los que el número de señales exceda el número de bits disponibles en un entero. El 
empleo de las fúnciones de biblioteca ayuda a lograr que MINIX sea fácilmente transportable a diferentes 
arquitecturas. 

Por último, se llenan los demás campos relacionados con señales en la parte de la tabla de 
procesos que corresponde al administrador de memoria. Para cada posible señal hay un mapa de bits, 
samask, que define cuáles señales deben bloquearse mientras se está ejecutando un manejador de esa 
señal. También hay un apuntador, sa handler, para cada posible señal, el cual puede contener un 
apuntador a la función de manejo, o valores especiales para indicar que la señal debe ignorarse o 
manejarse de la forma predeterminada. La dirección de la rutina de biblioteca que invoca SIGRETURN 
cuando el manejador termina está almacenada en mp sigretum. Esta dirección es uno de los campos del 
mensaje que el administrador de memoria recibe. 

POSIX permite que un proceso manipule su propio manejo de señales, incluso estando dentro de 
un manejador de señales. Esto puede servir para modificar la respuesta a señales subsecuentes mi entras se 
está procesando una señal, y luego restablecer el conjunto normal de respuestas. El siguiente grupo de 
llamadas al sistema apoya estas capacidades de manipulación de señales. SIGPENDING 
se maneja con dosigpending (línea 17889), que devuelve el mapa de bits 
mpsigpendmg para que un proceso pueda determinar si tiene señales pendientes. 
SIGPROCMASK, que se maneja con dosigprocmask, devuelve el conjunto de señales que actualmente 
están bloqueadas, y también puede servir para cambiar el estado de una sola señal del conjunto, o sustituir 
todo el conjunto por uno nuevo. El momento en el que una señal se desbloquea es el punto apropiado para 
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verificar si hay señales pendientes, y esto se hace con llamadas a check_pending en la línea 17927 y en la 
17933. Do sigsuspend (línea 17949) ejecuta la llamada al sistema SIGSUSPEND. Esta llamada suspende 
un proceso hasta que se recibe una señal. Al igual que las otras funciones que hemos visto aquí, ésta 
manipula mapas de bits, y además enciende el bit SIGSUSPENDED de mpflags, que es lo único que se 
necesita para impedir la ejecución de un proceso. Una vez más, éste es un buen momento para invocar 
check_pending. Por último, do sigretum maneja SIGRETURN, que sirve para regresar de un manejador 
personalizado. Esta Junción restablece el contexto de señales que existía cuando se ingresó en el 
manejador, y también invoca check_pending en la línea 17980. 

Algunas señales, como SIGINT, se originan en el kemel mismo. Tales señales se manejan de 
forma similar a las señales generadas por un proceso de usuario que invoca KILL. Los dos 
procedimientos, dokill (línea 17983) y doksig (línea 17994) son conceptualmente similares; ambos 
hacen que el administrador de memoria envíe una señal. Una sola llamada a KILL puede requerir el envío 
de señales a un grupo de procesos, y do kill se li mi ta a invocar checksig, que examina toda la tabla de 
procesos en busca de destinatarios elegibles. Se invoca do ksig cuando llega un mensaje del kemel. El 
mensaje contiene un mapa de bits, lo que permite al kemel generar múltiples señales con un solo mensaje. 
Al igual que con KILL, cualquiera de éstas podría tenerse que entregar a un grupo de procesos. El mapa 
de bits se procesa bit por bit en el ciclo de las líneas 18026 a 18048. Algunas señales del kemel requieren 
atención especial: en algunos casos se cambia el identificador de proceso para hacer que la señal se 
entregue a un grupo de procesos (líneas 18030 a 18033), y se hace caso omiso de un SIGALRM si no fue 
solicitado. Con esa excepción, cada bit encendido causa una llamada a check sig, tal como sucede en 
dokill. 

La llamada al sistema ALARM está bajo el control de doalarm (línea 18056). Ésta invoca la 
siguiente Junción, setalarm, que envía un mensaje a la tarea del reloj pidiéndole que ponga en marcha el 
temporizador. Set alarm (línea 18067) es una Junción aparte porque también se usa para apagar el 
temporizador cuando un proceso sale con el temporizador encendido aún. Cuando el temporizador llega a 
cero, el kemel anuncia el hecho enviando al administrador de memoria un mensaje del tipo KSIG, que 
causa la ejecución de do ksig, como ya se explicó. La acción predeterminada de la señal SIGALRM es 
ter mi n a r el proceso si no es atrapada. Si se desea atrapar SIGALRM, SIGACTION debe instalar un 
manejador. La secuencia completa de sucesos para una señal SIGALRM con un manejador personalizado 
se muestra en la Fig. 4-45. Hay tres secuencias de mensajes aquí. En los mensajes (1), (2) y (3) el usuario 
ejecuta una llamada ALARM mediante un mensaje al administrador de memoria, el cual envía una 
solicitud al reloj, de la cual el reloj acusa recibo. En los mensajes (4), (5) y (6), la tarea del reloj envía la 
alarma al administrador de memoria, éste llama a la tarea del sistema con el fin de que prepare la pila del 
proceso de usuario para la ejecución del manejador de señales (como en la Fig. 4-42(b)), y la tarea del 
sistema responde. El mensaje (7) es la llamada a SIGRETURN que ocurre cuando el manejador termina 
de ejecutarse. Como respuesta, el administrador de memoria envía el mensaje (8) a la tarea del sistema 
pidiéndole que complete el aseo, y la tarea del sistema responde con el mensaje (9). El mensaje (6) por sí 
solo no hace que se ejecute el manejador, pero la secuencia se mantendrá porque la tarea del sistema, al 
ser una tarea, podrá completar su trabajo gracias al algoritmo de planificación por prioridad que MINK 
emplea. El manejador forma parte del proceso de usuario y se ejecutará sólo después de que la tarea del 
sistema haya completado su trabajo. 
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Figura 4-45. Mensajes para una alarma. Los más importantes son: (1) El usuario ejecuta 
alarm. (4) Una ve/ transcurrido el tiempo establecido, llega la señal. (7) El manejador termina 
con una llamada a sigreturn. Consúltense los detalles en el texto. 


Do_pause se ocupa de la llamada al sistema PAUSE (línea 18115). Lo único que se necesitaos 
encender un bit y abstenerse de responder, manteniendo así al invocador bloqueado. Ni siquiera es 
necesario informar al kemel, ya que él sabe que el invocador está bloqueado. 

La última llamada al sistema que se maneja en signal.c es REBOOT (línea 18128). Esta llamada, 
la emple an sólo programas especializados ejecutables por el superusuario, pero realiza una fúnción 
importante: asegura que todos los procesos terminen de forma ordenada y que el sistema de archivos esté 
sincronizado antes de que se invoque la tarea del sistema en el kemel para concluir operaciones. La 
terminación de los procesos se efectúa utilizando check sig para enviar un siGKILLi a todos los procesos 
excepto init. Es por esta razón que REBOOT se incluyó en este archivo. 

Hemos mencionado de paso varias fúnciones de apoyo de signal.c. Ahora las examinaremoSil de 
forma más detallada. Por mucho, la más importante es sig_proc (línea 18168), que es la que realmente 
envía las señales. Primero se efectúa una serie de pruebas. Los intentos por enviar señales a procesos 
muertos (líneas 18190 a 18192) o zombis (líneas 18194 a 18196) son problemas 
graves que causan un pánico del sistema. Un proceso que se está rastreando se 
detienes cuando recibe una señal (líneas 18198a 18202). Si hay que ignorar la señal, el trabajo de 
sig_prwn ter mi na en la línea 18204. Ésta es la acción predeterminada para algunas señales, por ejemplo: 
aquellas que POSIX exige pero que MINIX no apoya. Si la señal se bloquea, la única acción 
que se debe emprender es encender un bit en el mapa de bits mp sigpending del proceso en cuestión. La 
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prueba clave (línea 18213) consiste en distinguir entre los procesos que están habilitados para atrapar 
señales y los que no lo están. A estas alturas ya se han eliminado todas las demás consideraciones 
especiales y si un proceso no puede atrapar la señal será terminado. 

Las señales que son elegibles para atraparse se procesan en las líneas 18214 a 18249. Se construye 
un mensaje que se enviará al kemel; partes de dicho mensaje son copias de información que está en la 
parte de la tabla de procesos que corresponde al administrador de memoria. Si el proceso al que se enviará 
la señal se había suspendido previamente con SIGSUSPEND, se incluye en el mensaje la máscara de 
señales que se guardó en el momento de la suspensión; si no, se incluye la máscara de señal actual (líneas 
18213 a 18217). Otros elementos que se incluyen en el mensaje son varias direcciones en el espacio del 
proceso al que se envía la señal: el manejador de señales, la dirección de la rutina de biblioteca sigretum 
que se invocará cuando el manejador termine, y el apuntador a la pila actual. 

A continuación, se asigna espacio en la pila del proceso. En la Fig. 4-46 se muestra la estructura 
que se coloca en la pila. La porción sigcontext se coloca en la pila a fin de conservarla para una 
restauración posterior, ya que la estructura correspondiente en la tabla de procesos misma se altera como 
preparación para la ejecución del manejador de señales. La parte sigframe proporciona una dirección de 
retomo para el manejador de señales y datos que SIGRETURN necesita para completar la restauración del 
estado del proceso cuando el manejador acaba. La dirección de retomo y el apuntador al marco no son 
utilizados realmente por ninguna parte de MINIX; están ahí para engañar a un depurador por si alguien 
intentara rastrear la ejecución de un manejador de señales. 

La estructura que se colocará en la pila del proceso destinatario de la señal es más o menos 
grande. El código de las líneas 18225 y 18226 reserva espacio para ella, después de lo cual una llamada a 
adjust prueba si hay suficiente espacio en la pila del proceso. Si no hay suficiente espacio de pila, se 
ter mi n a el proceso mediante un salto al rótulo determínate empleando el pocas veces usado goto de C 
(líneas 18228 y 18229). 

Hay un problema potencial con la llamada a adjust. Recuerde que cuando explicamos la 
implementación de BRK dijimos que adjust devuelve un error si la pila tiene menos de SAFETY BYTES 
de toparse con el segmento de datos. Se proporciona el margen de error adicional porque el software sólo 
puede verificar ocasionalmente la validez de la pila. Dicho margen de error probablemente sea excesivo 
en el presente caso, ya que se sabe exactamente cuánto espacio se necesita en la pila para la señal, y sólo 
se requiere espacio adicional para el manejador de señal, que supuestamente es una función relativamente 
sencilla. Es posible que algunos procesos se terminen innecesariamente porque falla la llamada a adjust. 
Sin duda, esto es mejor que experimentar fallas misteriosas de los programas en otras ocasiones, pero 
podría ser posible afinar un poco más estas pruebas. 

Si hay suficiente espacio en la pila, se verifican otras dos banderas. La bandera SA NODEFER 
indica si el proceso al que se envía la señal debe bloquear las señales subsecuentes del mismo tipo 
mientras maneja una señal. La bandera SA RESETHAND indica si el manejador de señales 
debe restablecerse al recibir esta señal. (Esto ofrece una fiel emulación de la antigua 
llamada signal. Aunque esta "capacidad" suele considerarse como un defecto de la antigua llamada, el 
apoyo de capacidades anteriores también implica apoyar sus defectos.) A continuación se notifica al 
kemel, empleando la rutina de biblioteca sys sendsig (línea 18242). Por último, se pone en cero el bit que 
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Figura 4-46. Las estructuras sigcontext y sigframe que se incorporan a la pila como prepara¬ 
ción para la ejecución de un manejador de señales. Los registros del procesador son una copia 
del marco de pila empleado durante una conmutación de contexto. 


indica que hay una señal pendiente y se invoca un pause para terminar cualquier llamada al sistema que el 
proceso pueda estar esperando. La próxima vez que se ejecute el proceso al que se envió la señal, se 
ejecutará el manejador de señales. 

Examinemos ahora el código de terminación, marcado por el rótulo determínate (línea 18250), El 
rótulo y un goto son la forma más fácil de manejar la posible falla de la llamada a adjust. Aquí se'! 
procesan las señales que por una razón u otra no se pueden o no se deben atrapar. La acción podría; incluir 
un vaciado de núcleo, si resulta apropiado para la señal, y siempre concluye con la terminación del 
proceso como si éste hubiera salido, a través de una llamada a mmexit (línea 18258). 

Checksig (línea 18265) es donde el administrador de memoria verifica si es posible enviar una 
señal. La llamada 

kill(0, sig); 

hace que se envíe la señal indicada a todos los procesos del grupo del usuario (es decir, todos los 
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procesos iniciados desde la misma terminal). Las señales que se originan en el kemel y REBOOT también 
podrían afectar múltiples procesos. Por esta razón, checksig ejecuta un ciclo en las líneas 18288 a 18318 
para examinar la tabla de procesos en busca de todos los procesos a los que se debe enviar una señal. El 
ciclo contiene un gran número de pruebas. Sólo si se satisfacen todas las condiciones se envía la señal, 
invocando sig_proc en la línea 18315. 

Check_pending (línea 18330) es otra fúnción que se invoca varias veces en el código que 
acabamos de explicar. Ésta ejecuta un ciclo para examinar todos los bits del mapa de bits mp sigpending 
correspondiente al proceso al que hacen referencia dosigmask, dosigretum o do sigsuspend, con objeto 
de ver si alguna señal bloqueada ha quedado desbloqueada. Check_pending invoca sig_proc para enviar la 
primera señal pendiente desbloqueada que encuentra. Puesto que todos los manejadores de señales tarde o 
temprano causan la ejecución de do sigretum, esto basta para finalmente entregar todas las señales no 
enmascaradas pendientes. 

El procedimiento unpause (línea 18359) tiene que ver con las señales que se envían a procesos 
supendidos en llamadas PAUSE, WAIT, READ, WRITE o SIGSUSPEND. PAUSE, WAIT y 
SIGSUSPEND pueden verificarse consultando la parte de la tabla de procesos que corresponde al 
administrador de memoria, pero si no se encuentra ninguna de éstas será necesario pedir al sistema de 
archivos que use su propia fúnción do unpause para verificar si hay una posible espera por READ o 
WRITE. 

En todos los casos la acción es la misma: se envía una respuesta de error a la llamada que espera y 
se pone en cero el bit de bandera que corresponde a la causa de la espera para que el proceso pueda 
reanudar su ejecución y procesar la señal. 

El último procedimiento de este archivo es dumpcore (línea 18402), que escribe vaciados de 
núcleo en el disco. Un vaciado de núcleo consiste en una cabecera con información relativa al tamaño de 
los segmentos ocupados por un proceso, una copia de toda la información de estado del proceso, obtenida 
copiando la información de tabla de procesos del kemel correspondiente a ese proceso, y la imagen de 
memoria de cada uno de los segmentos. Un depurador puede interpretar esta información y ayudar al 
programador a determinar qué error hubo durante la ejecución del proceso. El código para escribir el 
archivo es sencillo. El problema potencial que mencionamos en la sección anterior vuelve a asomar la 
cabeza, pero en una forma un tanto diferente. Para asegurar que el segmento de pila que se incluirá en el 
vaciado de núcleo está actualizado, se invoca adjust en la línea 18428. Esta llamada podría fallar a causa 
del margen de seguridad incorporado en ella. Dump core no comprueba que la llamada haya tenido éxito, 
así que el vaciado de núcleo se escribirá de todos modos, pero cabe la posibilidad que dentro del archivo 
la información relativa a la pila sea incorrecta. 

4.8.7 Implementación de las otras llamadas al sistema 

El archivo getset.c contiene un procedimiento, do getset (línea 18515), que ejecuta las siete llamadas 
restantes del administrador de memoria. Éstas se muestran en la Fig. 4-47. Todas son tan senciillas que no 
merecen un procedimiento completo para cada una. Las llamadas GETUID y GETGID welven el uid o gid 
tanto real como efectivo. 

El establecimiento del uid o el gid es un poco más complejo que su mera lectura. 
Se debe comprobar si el invocador está autorizado para establecer el uid o gid. Si el invocador pasa la 
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Llamada al sistema 

Descripción 

GETUID 

Devuelve uid real y efectivo 

GETGID 

Devuelve gid real y efectivo 

GETPID 

Devuelve pids del proceso y su padre 

SETUID 

Establece el uid real y efectivo del invocador 

SETGID 

Establece el gid real y efectivo del invocador 

SETSID 

Crea nueva sesión, devolver pid 

GETPGRP 

Devuelve identificador del grupo de procesos 


Figura 4-47. Las llamadas al sistema apoyadas en mm/getset.c. 


prueba, se debe informar al sistema de archivos del nuevo uid o gid, ya que la protección de los archivos 
depende de ello. La llamada SETSID crea una nueva sesión, y un proceso que ya es líder de un grupo de 
procesos no está autorizado a llevar esto a cabo. La prueba de la línea 18561 verifica esto. El sistema de 
archivos completa el trabajo de convertir un proceso en líder de sesión sin terminal controladora. 

El apoyo mínimo para la depuración, mediante la llamada al sistema PTRACE, está contenido en 
el archivo trace, c. Hay once comandos que pueden proporcionarse como parámetro a la llamada al 
sistema PTRACE. Éstos se muestran en la Fig. 4-48. En el administrador de memoria, doJrace procesa 
cuatro de ellos: enable (habilitar), exit (salir), resume (reanudar), step (pasos). Las solicitudes de habilitar 
el rastreo o salir de él se atienden aquí. Todos los demás comandos se pasan a la tarea del sistema, que 
tiene acceso a la parte del kemel de la tabla de procesos. Esto se hace con la llamada a la función de 
biblioteca sys trace en la línea 18669. Al final de trace.c se incluyen dos funciones de apoyo para el 
rastreo. Stop_proc sirve para detener un proceso rastreado cuando se le envía una señal, y findproc apoya 
do trace buscando en la tabla de procesos el proceso que se va a rastrear. 

4.8.8 Utilerías del administrador de memoria 

El resto de los archivos contienen rutinas de utilería y tablas. El archivo alloc.c es donde el| sistema toma 
nota de qué partes de la memoria están en uso y cuáles están libres. Hay cuatreJ puntos de entrada: 

1. allocmem - solicitar un bloque de memoria de cierto tamaño. 

2. freemem - devolver memoria que ya no se necesita. 

3. maxhole - calcular el tamaño del agujero más grande disponible. 

4. meminit - inicializar la lista libre cuando el administrador de memoria comienza a 

ejecutarse. 

Como ya dijimos, alloc mem (línea 18840) utiliza primer ajuste con una lista de agujeros ordenados 
según su dirección en la memoria. Si alloc mem encuentra un fragmento demasía 
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Comando 

Descripción 

T_STOP 

Detiene el proceso 

Ptjdk 

Habilita el rastreo por el padre para este proceso 

| T.GETINS 

Devuelve valor del espacio de texto (instrucciones) 

T_GETDATA 

Devuelve valor del espacio de datos 

j"T GETUSER 

Devuelve valor de la tabla de procesos de usuario 

T_SET1NS _ 

Establece valor en espacio de instrucciones 

T.SETDATA 

r Establece valor en espacio de datos 

T.SETUSER 

Establece valor en tabla da procesos de usuario 

T RESUME 

Reanuda eiecudón 

T EXIT 

| Sale 

T_STEP 

| Establece bit de rastreo 


Figura 4-48. Comandos de depuración apoyados por mm/trace.c. 


grande, toma lo que necesita y deja el resto en la lista libre, pero reduciendo su tamaño en la cantidad 
tomada. Si se requiere un agujero completo, se invoca del slot (línea 18926) para quitar la entrada de la 
lista libre. 

El trabajo defreemem consiste en verificar si una porción de memoria recién liberada se puede 
fusionar con agujeros adyacentes. Si se puede, se invoca merge (línea 18949) para unir los agujeros y 
actualizar las listas. 

MaxJiole (línea 18985) examina la lista de agujeros y devuelve el elemento más grande que 
encuentra. Meminit (línea 19005) construye la lista libre inicial, que incluye toda la memoria disponible. 

El siguiente archivo es utility.c, que contiene unos cuantos procedimientos diversos empleados en 
distintos puntos del administrador de memoria. El procedimiento allowed (línea 19120) verifica si se 
permite un acceso dado a un archivo. Por ejemplo, do exec necesita saber si un archivo es ejecutable. 

El procedimiento no sys (línea 19161) nunca debe invocarse. Se incluye sólo por si un usuario 
llega a invocar el administrador de memoria con un número de llamada al sistema que no es válido o que 
no está entre los que el administrador de memoria maneja. 

Panic (línea 19172) se invoca sólo cuando el administrador de memoria detecta un error del cual 
no se puede recuperar. Este procedimiento informa del error a la tarea del sistema, la cual entonces detiene 
MINIX de inmediato. Panic sólo se invoca en situaciones graves. 

La última fúnción de utility.c es tell fs, que construye un mensaje y lo envía al sistema de I 
archivos cuando se debe informar a éste de sucesos manejados por el administrador de memoria. Los dos 
procedimientos del archivo putk.c también son utilerías, aunque de índole muy dista de los anteriores. De 
vez en cuando se insertan llamadas a printf en el administrador de 
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memoria, principalmente para fines de depuración. Además, panic invoca printf. Como se mencionó antes, 
el nombre printf es en realidad una macro definida comoprintk, así que las llamadas a printfno usan el 
procedimiento de biblioteca de E/S estándar que envía mensajes al sistema de archivos. Printk invoca putk 
para comunicarse directamente con la tarea de la terminal, algo que está prohibido para los usuarios 
ordinarios. Vimos una rutina con el mismo nombre en el código del kemel. 

4.9 RESUMEN 

En este capítulo examinamos la administración de memoria, tanto en general como en MINIX. Vimos que 
los sistemas más sencillos no realizan intercambios ni paginación. Una vez que un programa se carga en la 
memoria, permanece ahí hasta terminar. Algunos sistemas operativos sólo permiten un proceso a la vez en 
la memoria, mientras que otros apoyan la multiprogramación. 

El siguiente paso hacia arriba es el intercambio. Cuando se usa intercambio, el sistema puede 
manejar más procesos que los que cabrían en la memoria. Los procesos para los cuales no hay espacio se 
intercambian al disco. Puede seguirse la pista al espacio libre en la memoria y en el disco mediante un 
mapa de bits o una lista de agujeros. 

Las computadoras más avanzadas suelen tener alguna forma de memoria virtual. En la forma más 
simple, el espacio de direcciones de cada proceso se divide en bloques de tamaño uniforme llamados 
páginas, que se pueden colocar en cualquier marco de página que esté disponible en la memoria. Hay 
muchos algoritmos de reemplazo de páginas; dos de los más conocidos son el de segunda oportunidad y el 
de maduración. No basta escoger un algoritmo para lograr que los sistemas de paginación funcionen bien; 
deben cuidarse aspectos tales como la determinación del conjunto de trabajo, la política de asignación de 
memoria y el tamaño de las páginas. 

La segmentación ayuda a manejar estructuras de datos que cambian de tamaño durante 1 
ejecución, y simplifica la vinculación y la compartición. Además, cuando se usan segmentos más fácil 
proporcionar distintos niveles de protección a los diferentes segmentos. En algunos casos se combina la 
segmentación con paginación para crear una memoria virtual bidimensional. El sistema MULTICS y el 
Pentium de Intel apoyan la segmentación y la paginación. 

La administración de memoria en MINIX es sencilla. Se asigna memoria cuando un proa ejecuta 
una llamada al sistema FORK o EXEC. La memoria así asignada nunca se incrementa, se decrementa 
durante la vida del proceso. En los procesadores Intel, MINIX emplea dos modelos memoria. Los 
programas pequeños pueden tener sus instrucciones y sus datos en el mismo segmento de memoria. Los 
programas más grandes usan espacio de instrucciones y de separado (I y D separado). Los procesos con 
espacio I y D separado pueden compartir la porción de texto de su memoria, de modo que sólo es 
necesario asignar memoria para los datos y la durante un FORK. Esto también podría ser cierto durante un 
EXEC si otro proceso ya está u el texto que el nuevo programa necesita. 

La mayor parte del trabajo del administrador de memoria no tiene que ver con mantel tanto de la 
memoria libre, lo cual hace empleando una lista de agujeros y el algoritmo de ajuste, sino con ejecutar las 
llamadas al sistema relacionadas con administración de mi 
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Varias llamadas al sistema reconocen señales estilo POSIX, y puesto que la acción predeterminada de la 
mayor parte de las señales es terminar el proceso al que se envió la señal, resulta apropiado manejarlas en 
el administrador de memoria, que inicia la terminación de todos los procesos. El administrador de 
memoria también maneja varias llamadas al sistema que no están relacionadas directamente con la 
memoria, principalmente porque es más pequeño que el sistema de archivos, así que resultó más cómodo 
colocarlas ahí. 


PROBLEMAS 

1. Un sistema de computadora tiene suficiente espacio para contener cuatro programas en su memoria 
principal. La mitad del tiempo, estos programas están ociosos esperando E/S. ¿Qué fracción del tiempo de 
CPU se desperdicia? 

2. Considere un sistema de intercambio en el que la memoria tiene agujeros con los siguientes tamaños en 
orden según su posición en la memoria: 10K, 4K, 20K, 18K, 7K, 9K, 12K y 15K. ¿Cuál agujero se toma 
cuando hay solicitudes de segmento sucesivas de 

(a) 12K 

(b) 10K 

(c) 9K 

si se usa primer ajuste? Repil;). usando mejor ajuste, peor ajuste y siguiente ajuste. 

3. ¿Qué diferencia hay entre una dirección física y una dirección virtual? 

4. Empleando la tabla de páginas de la Fig. 4-8, dé la dirección física que corresponde a cada una de las 
siguientes direcciones virtuales: 

(a) 20 

(b) 4100 

(c) 8300 

5. El procesador Intel 8086 no apoya la memoria virtual. No obstante, algunas compañías vendieron 
previamente sistemas que contenían una CPU 8086 no modificada y realizaban paginación. Utilice lo que 
sabe para sugerir cómo lo hicieron. (Sugerencia: piense en la ubicación lógica de la MMU.) 

6. Si una instrucción tarda 1 microsegundo y una falla de página tarda n microsegundos adicionales, 
deduzca una fórmula para el tiempo de instrucción efectivo si ocurren fallas de página cada k 
instrucciones. 

7. Una máquina tiene un espacio de direcciones de 32 bits y páginas de 8K. La tabla de páginas está 
totalmente en hardware, con una palabra de 32 bits por cada entrada. Cuando un proceso inicia, la tabla de 
páginas se copia en el hardware desde la memoria, a razón de una palabra cada 100 ns. Si cada proceso se 
ejecuta durante 100 ms (incluido el tiempo que toma cargar la tabla de páginas), ¿qué fracción del tiempo 
de CPU se dedica a cargar las tablas de páginas? 

8. Una computadora con direcciones de 32 bits usa una tabla de páginas de dos niveles. Las direcciones 
virtuales se dividen en un campo de tabla de páginas de nivel superior de nueve bits y un campo de tabla 
de páginas de segundo nivel de once bits, además de una distancia. ¿Qué tamaño tienen las páginas y 
cuántas de ellas hay en el espacio de direcciones? 
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9. A continuación se lista un programa corto en lenguaje ensamblador para una computadora con página; 
de 512 bytes. El programa reside en la dirección 1020, y su apuntador a la pila está en 8192 (la pila crece 
hacia 0). Dé la cadena de referencia a página generada por este programa. Cada instrucción ocupa cuatro 
bytes (una palabra), y las referencias tanto a instrucciones como a datos cuentan en 1. cadena de 
referencia. 

Cargar la palabra 6144 en el registro O 
Meter el registro O en la pila 

Invocar un procedimiento en 5120, agregando la dirección de retomo a la pila 
Restar la constante inmediata 16 del apuntador a la pila 
Comparar el parámetro real con la constante inmediata 4 
Saltar si es igual a 5152 

10. Suponga que una dirección virtual de 32 bits se divide en cuatro campos, a, b, c y d. Los primeros tres 
se utilizan para un sistema de tablas de páginas de tres niveles. El cuarto campo, d, es la distancia. ¿El 
número de páginas depende de los tamaños de los cuatro campos? Si no es así, ¿cuáles importan y cuáles 
no? 

11. Una computadora cuyos procesos tienen 1024 páginas en sus espacios de direcciones mantiene sus 
tablas de páginas en la memoria. El gasto extra requerido para leer una palabra de la tabla de páginas es de 
500 ns. Con objeto de reducir este gasto extra, la computadora tiene un TLB, que contiene 32 pares 
(página virtual, marco de página físico) y puede realizar una consulta en 100 ns. ¿Qué tasa de aciertos se 
necesita para reducir el gasto medio a 200 ns? 

12. El TLB del VAX no contiene un bit R. ¿Por qué? 

13. Una máquina tiene direcciones virtuales de 48 bits y direcciones físicas de 32 bits. Las páginas son de 
8K. ¿Cuántas entradas debe tener la tabla de páginas? 

14. Una computadora tiene cuatro marcos de página. A continuación se muestran el tiempo de carga, el 
tiempo de último acceso y los bits R y M para cada página (los tiempos están en tics del reloj): 


Página 

Cargada 

Última ref. 

R M 

O 

126 

279 

O O 

1 

230 

260 

1 O 

2 

120 

272 

1 1 

3 

160 

280 

1 1 


(a) ¿Cuál página se reemplazará si se usa NRU? 

(b) ¿Cuál página se reemplazará si se usa FIFO? 

(c) ¿Cuál página se reemplazará si se usa LRU? 

(d) ¿Cuál página se reemplazará si se usa segunda oportunidad? 

15. Si se emplea reemplazo de páginas FIFO con cuatro marcos de página y ocho páginas, ¿cuántas fallas 
de página ocurrirán con la cadena de referencia 0172327103 si los cuatro marcos inicialmente están ; 
vacíos? Repita el problema suponiendo que se usa LRU. 

16. Una computadora pequeña tiene cuatro marcos de página. En el primer tic del reloj, los bits R son 111 
(la página O es O, el resto son 1). En tics del reloj subsecuentes, los valores son 1011,1010,1101,0010, 
1010, 1100 y 0001. Si se emplea el algoritmo de maduración con un contador de ocho bits, indique los 
valores de los cuatro contadores después del último tic. 
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17. ¿Qué tiempo toma cargar un programa de 64K de un disco cuyo tiempo de búsqueda medio es de 30 
ms, cuyo tiempo de rotación es de 20 ms y cuyas pistas contienen 32K 

(a) si se usan páginas de 2K? 

(b) si se usan páginas de 4K? 

Las páginas están distribuidas aleatoriamente en el disco. 

18. Una de las primeras máquinas de tiempo compartido, la PDP-1, tenía una memoria de 4K palabras de 
18 bits, y mantenía en memoria sólo un proceso a la vez. Cuando el planificador decidía ejecutar otro 
proceso, el proceso que estaba en la memoria se escribía en un tambor de paginación, con 4K palabras de 
18 bits alrededor de la circunferencia del tambor. El tambor podía comenzar a escribir (o leer) en 
cualquier palabra, no forzosamente en la palabra 0. ¿Por qué supone usted que se escogió este tambor? 

19. Una computadora proporciona a cada proceso 65 536 bytes de espacio de direcciones dividido en 
páginas de 4096 bytes. Cierto programa tiene un tamaño de texto de 32 768 bytes, un tamaño de datos de 
16 386 bytes y un tamaño de pila de 15 870 bytes. ¿Cabrá este programa en el espacio de direcciones? Si 
el tamaño de página fuera de 512 bytes, ¿cabría el programa? Recuerde que una página no puede contener 
partes de dos segmentos distintos. 

20. Se ha observado que el número de instrucciones ejecutadas entre dos fallas de página consecutivas es 
directamente proporcional al número de marcos de página asignados a un programa. Si se duplica la 
memoria disponible, el intervalo medio entre fallas de página también se duplica. Suponga que una 
instrucción normal tarda 1 microsegundo, pero si ocurre una falla de página tarda 2001 microsegundos (es 
decir, se requiere 2 ms para manejar la falla). Si un programa tarda 60 s en ejecutarse, y durante este 
tiempo experimenta 15 000 fallas de página, ¿cuánto tardaría en ejecutarse si hubiera el doble de memoria 
disponible? 

21. Un grupo de diseñadores de sistemas operativos para la Compañía de Computadoras Económicas está 
buscando formas de reducir la cantidad de almacenamiento de respaldo que requiere su nuevo sistema 
operativo. El gurú principal acaba de sugerir que no vale la pena molestarse por guardar el texto de 
programa en el área de intercambio; en vez de ello, se puede colocar directamente en la memoria por 
paginación desde el archivo binario cada vez que se necesite. ¿Tiene algún problema tal estrategia? 

22. Explique la diferencia entre fragmentación intema y extema. ¿Cuál de ellas ocurre en los sistemas con 
paginación? ¿Cuál ocurre en los sistemas que emplean segmentación pura? 

23. Cuando se usa tanto segmentación como paginación, como en MULTICS, primero hay que consultar 1 
descriptor de segmento y luego el descriptor de página. ¿El TLB funciona también de esta manera, con 
dos niveles de consulta? 

24. ¿Por qué el esquema de administración de memoria de MINIX obliga a tener un programa como 
hmemr! 

25. Modifique MINIX de modo que libere la memoria ocupada por un zombi tan pronto como el proceso 
pase al estado zombi, en lugar de esperar hasta que el padre ejecute WAIT por él. 

26. En la implementación actual de MINIX, cuando se efectúa una llamada al sistema EXEC, el 
dministrador de memoria verifica si está disponible un agujero con el tamaño suficiente para contener la 
nueva imagen de memoria. Si no lo hay, la llamada se rechaza. Un mejor algoritmo sería determinar si 
habrá un agujero con el tamaño requerido después de que se libere la imagen de memoria actual. 
Implemente este algoritmo. 

27. Al realizar una llamada al sistema EXEC, MINIX emplea un truco para hacer que el sistema de 
archivos lea segmentos enteros en una sola operación. Invente e implemento un truco similar para permitir 
que los vaciados de núcleo se escriban de la misma forma. 
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28. Modifique MINIX de modo que realice intercambio. 

29. En la sección 4.7.5 se señaló que, al efectuarse una llamada EXEC, el hecho de que la prueba para 
encontrar un agujero apropiado se realice antes de liberar la memoria del proceso actual da lugar a una 
implementación subóptima. Reprograme este algoritmo para que funcione mejor. 

30. En la sección 4.8.4 se apuntó que sería mejor buscar agujeros para los segmentos de texto y de datos 
por separado. Implemento esta mejora. 

31. Rediseñe adjust de modo que evite el problema de la terminación innecesaria de procesos destinatarios 
de señales a causa de una prueba demasiado estricta para determinar si hay suficiente espacio de pila. 
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Todas las aplicaciones de computadora necesitan almacenar y recuperar información. Mientras un proceso 
se está ejecutando, puede almacenar una cantidad de información limitada dentro de su propio espacio de 
direcciones. Sin embargo, la capacidad de almacenamiento está restringida al tamaño del espacio de 
direcciones virtual. En el caso de algunas aplicaciones, este tamaño es adecuado, pero en el de otras, como 
las de reservaciones de líneas aéreas, las aplicaciones bancadas o las bases de datos corporativas, dicho 
tamaño resulta excesivamente pequeño. 

Un segundo problema de mantener la información dentro del espacio de direcciones de un proceso 
es que cuando el proceso ter min a la información se pierde. En muchas aplicaciones (como las bases de 
datos), la información debe retenerse durante semanas, meses, o incluso eternamente. No es aceptable que 
la información desaparezca cuando el proceso que la está usando termina. Además, la información no 
debe perderse cuando una caída de la computadora termina el proceso. 

Un tercer problema es que en muchos casos es necesario que múltiples procesos accedan a (partes 
de) la información al mismo tiempo. Si tenemos un directorio telefónico en línea almacenado dentro del 
espacio de direcciones de un solo proceso, únicamente ese proceso tendrá acceso a él. La forma de 
resolver este problema es hacer que la información misma sea independiente de cualquier proceso 
individual. 

Por tanto, tenemos tres requisitos esenciales para el almacenamiento de información a largo plazo: 

1. Debe ser posible almacenar una gran cantidad de información. 

2. La información debe sobrevivir a la terminación del proceso que la usa. 

3. Múltiples procesos deben poder acceder a la información de forma concurrente. 

La solución usual a todas estas exigencias es almacenar la información en discos y 
otros medios externos en unidades llamadas archivos. Así, los procesos pueden leerlos y escribir archivos 
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nuevos si es necesario. La información almacenada en archivos debe ser persistente, es decir, no ser 
afectada por la creación y ter mi nación de procesos. Un archivo sólo debe desaparecer cuando su 
propietario lo elimina explícitamente. 

Los archivos son administrados por el sistema operativo. La forma como se estructuran, nombran, 
acceden, usan, protegen e implementan son temas importantes en el diseño de sistemas operativos. 
Globalmente, la parte del sistema operativo que se ocupa de los archivos se denomina sistema de 
archivos y es el tema de este capítulo. 

Desde el punto de vista del usuario, el aspecto más importante de un sistema de archivos es la cara 
que presenta ante él, es decir, qué constituye un archivo, cómo se nombran y protegen los archivos, qué 
operaciones pueden efectuarse con los archivos, etc. Los detalles de si se usan listas enlazadas o mapas de 
bits para mantenerse al tanto del espacio de almacenamiento disponible y de cuántos sectores hay en un 
bloque lógico tienen menos interés, aunque son de gran relevancia para los diseñadores del sistema de 
archivos. Por esta razón, hemos estructurado el capítulo en varias secciones. Las dos primeras se ocupan 
de la interfaz entre el usuario y los archivos y directorios, respectivamente. Luego viene una explicación 
detallada de cómo se implementa el sistema de archivos. Después, examinaremos la seguridad y los 
mecanismos de protección de los sistemas de archivos. Por último estudiaremos el sistema de archivos de 
MINIX. 

5.1 ARCHIVOS 

En esta sección consideraremos los archivos desde el punto de vista del usuario, es decir, cómo se usan y 
qué propiedades tienen. 

5.1.1 Nombres de archivos 

Los archivos son un mecanismo de abstracción; proporcionan una forma de almacenar información en el 
disco y leerla después. Esto debe hacerse de tal manera que el usuario no tenga que ocuparse de los 
detalles de cómo y dónde se almacena la información, ni de cómo funcionan realmente los discos. 

Tal vez la característica más importante de cualquier mecanismo de abstracción sea la forma como se 
nombran los objetos que se manejan, así que iniciaremos nuestro estudio de los sistemas de archivos con 
el tema de los nombres de archivos. Cuando un proceso crea un archivo, le | asigna un nombre. Cuando el 
proceso termina, el archivo sigue existiendo y otros procesos pueden acceder a él utilizando su nombre. 

Las reglas exactas para nombrar archivos varían un tanto de un sistema a otro, pero todos los 
sistemas operativos permiten cadenas de uno a ocho caracteres como nombres de archivo válidos. Así, 
andrea, braulio y caria son posibles nombres de archivo. En muchos casos se permiten: también dígitos y 
caracteres especiales, haciendo válidos también nombres como 2, urgente! y,| Fig.2-14. Muchos sistemas 
de archivos reconocen nombres de hasta 255 caracteres. 

Algunos sistemas de archivos distinguen entre las letras mayúsculas y minúsculas, y otros no. 
UNIX pertenece a la primera categoría; MS-DOS cae en la segunda. Por tanto, un sistema UNIX 
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puede tener todos los siguientes como archivos distintos: barbara. Barbara, BARBARA, BARbara y 
BarBaRa. En MS-DOS todos designan el mismo archivo. 

Muchos sistemas operativos reconocen nombres de archivo de dos partes, las cuales se separan 
con un punto, como en prog.c. La parte que sigue al punto se denomina extensión de archivo y, por lo 
regular, indica algo acerca del archivo. En MS-DOS, por ejemplo, los nombres de archivo tienen de 1 a 8 
caracteres, más una extensión opcional de 1 a 3 caracteres. En UNIX, el tamaño de la extensión, si la hay, 
es decisión del usuario, y un archivo incluso puede tener dos o más extensiones, como enprog.c.Z, donde 
.Z se emplea comúnmente para indicar que el archivo (prog.c) se compiló utilizando el algoritmo de 
compresión Ziv.Lempel. En la Fig. 5-1 se presentan algunas de las extensiones de archivo más comunes y 
su significado. 


Extensión 

Significado 

archivo.bak 

Archivo de respaldo 

archivo c 

Programa fuente en C 

archivo.f77 

Programa en Fortran 77 

archivo.g<f 

Formato de intercambio de gráficos de CompuServe 

archivo. Mp 

Archivo de ayuda 

archivo.html 

Documento en Lenguaje de Marcado de HiperTexto de la World Wide Web 

archivo, mpg 

Cine codificado con la norma MPEG 

archivo o 

Archivo objeto (salida del compilador, antes de enlazar) 

archivo.ps 

Archivo PostScript 

archrvo.tex 

Entrada para el programa de formateo TEX 

archrvotxt 

Archivo de texto general 

archivo.zip 

Archivo comprimido 


Figura 5-1. Algunas extensiones de archivo típicas. 


En algunos casos, las extensiones de archivo no son más que convenciones y su uso no es 
obligatorio. Un archivo llamado archivo.txt con toda probabilidad es algún tipo de archivo de texto, pero 
ese nombre sirve más como recordatorio para el propietario que para comunicar alguna información 
específica a la computadora. Por otro lado, un compilador de C podría exigir ; que los archivos que va a 
compilar terminen con .c, y podría negarse a compilarlos si no es así. 

Las convenciones como ésta tienen especial utilidad cuando el mismo programa puede manejar 
varios tipos de archivo distintos. El compilador de C, por ejemplo, puede recibir una lista de varios 
archivos para compilar y enlazar, algunos de ellos archivos en C y otros archivos en lenguaje 
ensamblador. En este caso la extensión se vuelve esencial para que el compilador distinga 
¡entre los archivos en C, los archivos en lenguaje ensamblador y los archivos de otro tipo. 



























404 


SISTEMAS DE ARCHIVOS 


CAP. 5 


5.1.2 Estructura de archivos 

Los archivos pueden estructurarse de varias maneras. Tres posibilidades comunes se representan en la Fig. 
5-2. El archivo de la Fig. 5-2(a) es una secuencia no estructurada de bytes. En efecto, el sistema operativo 
no sabe (ni le importa) qué contiene el archivo; lo único que ve es bytes. Cualquier significado que tenga 
deberán imponerlo los programas en el nivel de usuario. Tanto UNIX como MS-DOS adoptan este 
enfoque. Como acotación, WINDOWS 95 usa básicamente el sistema de archivos de MS-DOS, 
agregándole un poco de azúcar sintáctica (p. ej-, nombres de archivo largos), así que casi todo lo que 
digamos en este capítulo acerca de MS-DOS también aplica a WINDOWS 95. En cambio, WINDOWS 
NT es totalmente distinto. 



1 Byle 



Figura 5-2. Tres clases de archivos, (a) Secuencia de bytes. (b) Secuencia de registros, 
(c) Árbol. 


Hacer que el sistema operativo vea los archivos únicamente como secuencias de bytes ofrece el 
máximo de flexibilidad. Los programas de usuario pueden poner cualquier cosa que deseen los archivos y 
darles cualquier nombre que crean conveniente. El sistema operativo no ayuda, pero tampoco estorba. 
Para los usuarios que desean hacer cosas fúera de lo común, esto último es muy importante. 

El primer paso hacia arriba en cuestión de estructura se muestra en la Fig. 5-2(b). En este modelo, 
un archivo es una secuencia de registros de longitud fija, cada uno con cierta estructura interna. La idea de 
que un archivo es una secuencia de registros se apoya en el concepto de que la operación de lectura 
devuelve un registro y que la operación de escritura sobreescribe o anexa un registro. En el pasado, 
cuando la tarjeta perforada de 80 columnas era la reina y señora, muchos sistemas operativos basaban sus 
sistemas de archivos en archivos compuestos por registros de 80 caracteres, que, en efecto, eran imágenes 
de tarjetas. Estos sistemas también daban soporte a archivos con registros de 132 caracteres, pensados para 
la impresora de líneas (que en esos días era una impresora grande de cadenas con 132 columnas). Los 
programas leían las entradas en unidades de 80 caracteres y las escribían en unidades de 132 caracteres 
aunque, desde luego, los últimos 52 podían ser espacios. 
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Un sistema (antiguo) que consideraba los archivos como secuencias de registros de longitud fija 
era CP/M. Éste utilizaba registros de 128 caracteres. Hoy día, la idea de un archivo como una secuencia de 
registros de longitud fija es prácticamente cosa del pasado, aunque en otra época fue la norma. 

El tercer tipo de estructura de archivo se muestra en la Fig. 5-2(c). En esta organización, un 
archivo consiste en un árbol de registros, no necesariamente todos de la misma longitud, cada uno de los 
cuales contiene un campo de llave en una posición fija dentro del registro. El árbol está ordenado según el 
campo de llave, a fin de poder buscar rápidamente una llave en particular. 

La operación básica aquí no es obtener el "siguiente" registro, aunque eso también es posible, sino 
obtener el registro que tiene una llave dada. En el caso del archivo de zoológico de la Fig. 5-2(c), 
podríamos pedirle al sistema que obtenga el registro cuya llave es pony, por ejemplo, sin tener que 
preocupamos por su posición exacta en el archivo. Además, es posible agregar nuevos registros al archivo 
dejando que el sistema operativo, y no el usuario, decida dónde deben colocarse. Este tipo de archivo 
obviamente es muy distinto de los flujos de bytes no estructurados que se emplean en UNDC y MS-DOS, 
pero se utiliza ampliamente en las macrocomputadoras que todavía se usan en algunas aplicaciones 
comerciales de procesamiento de datos. 

5.1,3 Tipos de archivos 

Muchos sistemas operativos reconocen varios tipos de archivos. UNIX y MS-DOS, por ejemplo, tienen 
archivos normales y directorios. UNIX también tiene archivos especiales por caracteres y por bloques. Los 
archivos regulares son los que contienen información del usuario. Todos los archivos de la Fig. 5-2 son 
archivos normales. Los directorios son archivos de sistema que sirven para mantener la estructura del 
sistema de archivos. Estudiaremos los directorios más adelante. Los archivos especiales por caracteres 
están relacionados con entrada/salida y sirven para modelar dispositivos E/S en serie como las terminales, 
impresoras y redes. Los archivos especiales por bloques sirven para modelar discos. En este capítulo nos 
interesarán primordialmente los archivos normales. 

Los archivos normales generalmente son archivos ASCII o bien archivos binarios. Los archivos 
ASCII consisten en líneas de texto. En algunos sistemas cada línea termina con un carácter de retomo de 
carro; en otros se emplea el carácter de salto de línea. Ocasionalmente se requieren ambos. Las líneas no 
tienen que tener todas la misma longitud. 

La gran ventaja de los archivos ASCII es que pueden exhibirse e imprimirse tal como están, y se 
pueden editar con un editor de textos normal. Además, si una gran cantidad de programas usan archivos 
ASCII como entradas y salidas, es fácil conectar la salida de un programa a la entrada del otro, como en 
los conductos de shell. (La interconexión entre procesos no es más fácil, pero ciertamente lo es la 
interpretación de la información si se emplea una convención estándar, como ASCII, para expresarla.) 

Otros archivos son binarios, lo que simplemente significa que no son archivos ASCII. Si listamos 
estos archivos en una impresora, obtendremos un listado incomprensible lleno de lo que parece ser basura. 
Por lo regular, estos archivos tienen alguna estructura intema. 

Por ejemplo, en la Fig. 5-3(a) vemos un archivo binario ejecutable sencillo tomado de una de las 
primeras versiones de UNIX. Aunque técnicamente el archivo no es sino una secuencia de bytes, 1 
sistema operativo sólo ejecuta un archivo si éste tiene el formato correcto. El ejemplo tiene 
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cinco secciones: encabezado, texto, datos, bits de reubicación y tabla de símbolos. El encabezado 
comienza con lo que se conoce como un número mágico, que identifica el archivo como ejecutable (a fin 
de evitar la ejecución accidental de un archivo que no tiene este formato). Luego vienen enteros de 16 bits 
que indican los tamaños de los distintos componentes del archivo, la dirección en la que se inicia la 
ejecución y algunos bits de bandera. Después del encabezado vienen el texto y los datos del programa 
mismo. Éstos se cargan en la memoria y se reubican empleando los bits de reubicación. La tabla de 
símbolos sirve para la depuración. 



Número mágico 

Tamaño de texto 

Tamaño de datos 

Tamaño de B5S 

Tamaño de tabla 

Punto de entrada 

mmmrn. 

Banderas 

Texto 

Datos 

Bits 

de reumcacion 

: Tabla de símbolos - 


Figura 5-3. (a) Un archivo ejecutable, (b) Un archivo. 


Nuestro segundo ejemplo de archivo binario es un archivo de archivado, también de UNKs| Este 
archivo consiste en una colección de procedimientos de biblioteca (módulos) compilado»;! pero no 
enlazados. Cada módulo va precedido por un encabezado que indica su nombre, fechada creación, 
propietario, código de protección y tamaño. Al igual que en el archivo ejecutable, los encabezados de 
módulo están llenos de números binarios; si los copiáramos en una impresora obtendríamos un listado 
ininteligible. 

Todos los sistemas operativos deben reconocer un tipo de archivo, su propio archivo 
ejecutable, pero algunos reconocen más. El antiguo sistema TOPS-20 llegó al extremo de examinará 
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tiempo de creación de todo archivo por ejecutar; luego localizaba el archivo fuente y veía si éste se había 
modificado después de crearse el binario. Si tal era el caso, el sistema recompilaba automáticamente el 
archivo fuente. En términos de UNIX, se había incorporado el programa make en el shell. Las extensiones 
de archivo eran obligatorias para que el sistema operativo pudiera saber cuál programa binario se derivaba 
de cuál fuente. 

Algo por el estilo es lo que hace WINDOWS cuando un usuario hace doble clic sobre el nombre 
de un archivo: pone en marcha un programa apropiado con el nombre de archivo como parámetro. El 
sistema operativo determina cuál programa debe ejecutar basándose en la extensión del archivo. 

Tener archivos con tipificación estricta como éstos causa problemas siempre que el usuario hace 
algo que los diseñadores del sistema no esperaban. Consideremos, por ejemplo, un sistema en el que los 
archivos de salida de los programas tienen el tipo dat (archivos de datos). Si un usuario escribe un 
formateador de programas que lee un archivo .pas, lo transforma (p. ej., convirtiéndolo a una organización 
con sangrías estándar) y luego envía el archivo transformado a la salida, el archivo de salida será de tipo 
.dat. Si el usuario trata de ofrecer este archivo al compilador de Pascal para que lo compile, el sistema no 
lo permitirá porque el archivo no tiene la extensión correcta. El sistema rechazará los intentos por copiar 
archivo.dat en archivo.pas por considerarlos no válidos (tratando de proteger al usuario contra errores). 

Si bien este tipo de "amabilidad con el usuario" podría ayudar a los novatos, causa exasperación 
en los usuarios experimentados porque tienen que dedicar mucho trabajo a sortear la idea que se tiene del 
sistema operativo respecto a lo que es razonable y lo que no lo es. 

5.1.4 Acceso a archivos 

Los primeros sistemas operativos sólo ofrecían un tipo de acceso a los archivos: acceso secuencial. En 
estos sistemas, un proceso podía leer todos los bytes o registros de un archivo en orden, comenzando por 
el principio, pero no podía saltar de un lado a otro y leerlos en desorden. Los archivos secuenciales pueden 
"rebobinarse", así que pueden leerse tantas veces como sea necesario. Los archivos secuenciales son 
apropiados cuando el medio de almacenamiento es cinta magnética, no disco. 

Cuando comenzaron a usarse los discos para almacenar archivos, se hizo posible leer los bytes o 
registros de un archivo en desorden, o acceder a los registros por llave, no por posición. Los archivos 
cuyos bytes o registros se pueden leer en cualquier orden se denominan archivos de acceso aleatorio. 

Los archivos de acceso directo son esenciales para muchas aplicaciones, por ejemplo, los sistemas 
de bases de datos. Si un cliente de una línea aérea llama por teléfono y quiere reservar un asiento en un 
vuelo dado, el programa de reservación debe poder acceder al registro de ese vuelo sin tener que leer 
primero los registros de varios miles de otros vuelos. 

Se emplean dos métodos para especificar el punto donde debe iniciarse la lectura. En el primero, 
cada operación READ indica la posición dentro del archivo en la que se debe comenzar a leer. En el 
segundo, se cuenta con una operación especial, SEEK, para establecer la posición actual. Después de un 
SEEK, el archivo se puede leer secuencialmente a partir de la posición que ahora es la actual. 
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En algunos sistemas operativos de macrocomputadoras antiguas, los archivos se clasifican como 
secuenciales o de acceso directo en el momento en que se crean. Esto permite al sistema usar técnicas de 
almacenamiento diferentes para las dos clases. Los sistemas operativos modernos no hacen esta distinción; 
todos sus archivos son automáticamente de acceso directo. 

5.1.5 Atributos de archivos 

Todo archivo tiene un nombre y ciertos datos. Además, todos los sistemas operativos asocian información 
adicional a cada archivo, por ejemplo, la fecha y hora de creación del archivo, y su tamaño. Llamamos a 
estos datos adicionales atributos del archivo. La lista de atributos varía considerablemente de un sistema 
a otro. La tabla de la Fig. 5-4 muestra algunas de las posibilidades, pero existen otras. Ningún sistema 
existente tiene todos estos atributos, pero cada uno está presente en algún sistema. 


Campo 

Significado 

Protección 

Quién puede acceder al archivo y de qué modo 

Contraseña 

Contraseña requerida para acceder ai archivo 

Creador 

Identíficador de la persona que creó el archivo 

Propietario 

Propietario actual 

Bandera de sólo lectura 

0 a lectura/escritura; 1 = sólo lectura 

Bandera de oculto 

0 = normal; 1 « no mostrar en los listados 

Bandera de sistema 

0 - archivo normal; 1 « archivo de sistema 

Bandera de archivado 

0 ■ ya se respaldó; 1 * necesita respaldarse 

Bandera ASCII/binario 

0 = archivo ASCII; 1 a archivo binario 

Bandera de acceso aleatorio 

0 = sólo acceso secuencial; 1 = acceso aleatono 

Bandera de temporal 

0 = normal; 1 - eliminar al salir el proceso 

Banderas de candado 

0 = sin candado; diferente de cero = con candado 

Longitud de registro 

Número de bytes en cada registro 

Posición de la llave 

Distancia de la llave desde el principio de cada registro 

Longitud de la llave 

Número de bytes del campo de la llave 

Tiempo de creación 

Fecha y hora de creación del archivo 

Tiempo de último acceso 

Fecha y hora del último acceso al archivo 

Tiempo de último cambio 

Fecha y hora en que se modificó por última vez el archivo 1 

Tamaño actual j 

Número de bytes del archivo 

Tamaño máximo 

Número de bytes que puede llegar a tener el archivo 


Figura 5-4. Algunos posibles atributos de archivo. 


Los primeros cuatro atributos tienen que ver con la protección del archivo e indican quién puede 
acceder a él y quién no. Se puede utilizar todo tipo de esquemas, algunos de los cuales 
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estudiaremos más adelante. En algunos sistemas el usuario debe presentar una contraseña para acceder a 
un archivo, en cuyo caso la contraseña debe ser uno de los atributos. 

Las banderas son bits o campos cortos que controlan o habilitan alguna propiedad específica. Los 
archivos ocultos, por ejemplo, no aparecen en los listados de todos los archivos. La bandera de archivado 
es un bit que indica si el archivo ya se respaldó o no. El programa de respaldo lo pone en cero, y el sistema 
operativo lo pone en 1 cada vez que el archivo sufre alguna modificación. De este modo, el programa de 
respaldo puede saber cuáles archivos hay que respaldar. La bandera de temporal permite marcar un 
archivo para que sea borrado automáticamente cuando el proceso que lo creó termina. 

Los campos de longitud de registro, posición de la llave y longitud de la llave sólo están presentes 
en los archivos cuyos registros pueden consultarse empleando una llave. Dichos campos proporcionan la 
información requerida para encontrar las llaves. 

Los diversos tiempos mantienen un registro de cuándo se creó el archivo, cuándo se accedió a él 
por última vez y cuándo se modificó por última vez. Estos tiempos pueden servir para diversos fines. Por 
ejemplo, un archivo fuente que se modificó después de la creación del archivo objeto correspondiente 
debe recompilarse. Estos campos proporcionan la información necesaria. 

El tamaño actual indica qué tan grande es el archivo actualmente. Algunos sistemas operativos de 
macrocomputadoras exigen que se especifique un tamaño máximo en el momento de crearse un archivo, a 
fin de poder reservar la cantidad máxima de almacenamiento por adelantado. Los sistemas operativos de 
las estaciones de trabajo y las computadoras personales tienen la suficiente inteligencia como para 
prescindir de esta información. 

5.1.6 Operaciones con archivos 

Los archivos existen para almacenar información que posteriormente se pueda recuperar. Los diferentes 
sistemas ofrecen distintas operaciones de almacenamiento y recuperación. A continuación reseñamos las 
llamadas al sistema más comunes relacionadas con archivos. 

1. CRÉATE. El archivo se crea sin datos. El propósito de la llamada es anunciar que va a haber un 
archivo y establecer algunos de los atributos. 

2. DELETE. Cuando el archivo ya no se necesita, es preciso eliminarlo para desocupar el espacio 
en disco. Siempre hay una llamada al sistema para este fin. 

3. OPEN. Antes de usar un archivo, un proceso debe abrirlo. El propósito de la llamada OPEN es 
permitir al sistema que obtenga los atributos y la lista de direcciones de disco y los coloque en la memoria 
principal a fin de agilizar el acceso en llamadas posteriores. 

4. CLOSE. Una vez concluidos todos los accesos, los atributos y las direcciones de disco ya no 
son necesarios, por lo que se debe cerrar el archivo para liberar el espacio correspondiente en las tablas 
intemas. Muchos sistemas fomentan esto limitando a los procesos a un número máximo de archivos 
abiertos. Las escrituras en disco son por bloques, y el cierre de un archivo obliga a escribir el último 
bloque del archivo, aunque todavía no esté totalmente lleno. 
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5. READ. Se leen datos del archivo. Por lo regular, los bytes provienen de la posición actual. El 
invocador debe especificar cuántos datos se necesitan y también debe suministrar un buffer para 
colocarlos. 

6. WRITE. Se escriben datos en el archivo, también, por lo regular, en la posición actual. Si dicha 
posición es el final del archivo, el tamaño del archivo aumenta. Si la posición actual está a la mitad del 
archivo, se sobreescribe en los datos existentes, que se pierden irremediablemente. 

7. APPEND. Esta llamada es una forma restringida de WRITE que sólo puede agregar datos al 
final del archivo. Los sistemas que ofrecen un juego mínimo de llamadas al sistema generalmente no 
cuentan con APPEND, pero muchos sistemas ofrecen varias formas de hacer una misma cosa, y a veces 
incluyen APPEND. 

8. SEEK. En el caso de archivos de acceso aleatorio, se requiere un método para especificar el 
lugar del que deben tomarse los datos. Un enfoque común es tener una llamada al sistema, SEEK, que 
ajuste el apuntador a la posición actual haciéndolo que apunte a un lugar específico del archivo. Una vez 
efectuada esta llamada, se pueden leer datos de esa posición o escribirlos en ella. 

9. GET ATTRIBUTES. Es frecuente que los procesos necesiten leer los atributos de un archivo 
para realizar su trabajo. Por ejemplo, el progama make de UNIX se usa co- múnmente para administrar 
proyectos de desarrollo de software que constan de muchos archivos fuente. Cuando se invoca make, 
examina los tiempos de modificación de todos los archivos fuente y objeto y organiza el número mínimo 
decompilaciones necesarias para que todo esté actualizado. Para efectuar su trabajo, este comando necesita 
examinar algunos atributos, a saber, los tiempos de modificación. 

10. SET ATTRIBUTES. Algunos de los atributos pueden ser establecidos por el usuario y 
modificarse después de que se creó el archivo. Esta llamada al sistema hace posible esto. La información 
de modo de protección es un ejemplo obvio. La mayor parte de las banderas también pertenecen a esta 
categoría. 

11. RENAME. Es común que un usuario necesite cambiar el nombre de un archivo existente. Esta 
llamada permite hacerlo, aunque no siempre es indispensable, ya que el archivo por lo regular puede 
copiarse en un archivo nuevo con el nuevo nombre, eliminando después el archivo viejo. 

5,2 DIRECTORIOS 

A fin de organizar los archivos, los sistemas de archivos casi siempre tienen directorios que en muchos 
sistemas, son también archivos. En esta sección hablaremos de los directorios, su organización, sus 
propiedades y las operaciones que pueden efectuarse con ellos. 
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5.2.1 Sistemas de directorio jerárquicos 

Un directorio normalmente contiene varias entradas, una por archivo. Una posibilidad se muestra en la 
Fig. 5-5(a), donde cada entrada contiene el nombre del archivo, los atributos del archivo, y la dirección de 
disco donde están almacenados los datos. Otra posibilidad se muestra en la Fig. 5-5(b). Aquí una entrada 
de directorio contiene el nombre del archivo y un apuntador a otra estructura de datos en la que pueden 
encontrarse los atributos y las direcciones en disco. Ambos sistemas son de uso generalizado. 


juegos ; atributos 


correo ! atributos 


noticias > atributos 


trabajo j atributos 


(a) 



Figura 5-5. (a) Atributos en la entrada de directorio, (b) Atributos en otro lugar. 


Cuando se abre un archivo, el sistema operativo examina su directorio hasta encontrar el nombre 
del archivo por abrir, y luego extrae los atributos y las direcciones en disco, ya sea directamente de la 
entrada de directorio o de la estructura de datos a la que ésta apunta, y los coloca en una tabla en la 
memoria principal. Todas las referencias subsecuentes al archivo utilizan la información que está en la 
memoria principal. 

El número de direcciones varía de un sistema a otro. El diseño más sencillo es aquel en el que el 
sistema mantiene un solo directorio que contiene todos los archivos de todos los usuarios, como se ilustra 
en la Fig. 5-6(a). Si hay muchos usuarios, y éstos escogen los mismos nombres de archivo (p. ej., correo y 
juegos), los conflictos y la confusión resultante pronto harán inmanejable el sistema. Este modelo se 
utilizó en los primeros sistemas operativos de microcomputadoras, pero ya casi nunca se encuentra. 

Una mejora de la idea de tener un solo directorio para todos los archivos del sistema es tener un 
directorio por usuario [véase la Fig. 5-6(b)]. Este diseño elimina los conflictos de nombres entre usuarios 
pero no es satisfactorio para quienes tienen un gran número de archivos. Es muy común que los usuarios 
quieran agrupar sus archivos atendiendo a patrones lógicos. Un profesor, por ejemplo, podría tener una 
colección de archivos que juntos constituyan un libro que está escribiendo para un curso, una segunda 
colección de archivos que contenga programas que los estudiantes de otro curso hayan presentado, un 
tercer grupo de archivos que contenga el código de un sistema avanzado de escritura de compiladores que 
él esté construyendo, un cuarto grupo de archivos que contenga propuestas para obtener subvenciones, así 
como otros archivos para correoelectrónico, minutas de reuniones, artículos que esté escribiendo, juegos, 
etc. Se requiere algún método para agrupar estos archivos en formas flexibles elegidas por el usuario. 
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Figura 5*6. Tres diseños de sistema de archivos, (a) Un solo directorio compartido por todos 
los usuarios, (b) Un directorio por usuario, (c) Árbol arbitrario por usuario. Las letras indican 
el propietario del directorio o archivo. 


Lo que hace falta es una jerarquía general (es decir, un árbol de directorios). Con este enfoque, 
cada usuario puede tener tantos directorios como necesite para poder agrupar sus archivo) según patrones 
naturales. Este enfoque se muestra en la Pig. 5-6(c). Aquí, los directorios A, ¿?| C, contenidos en el 
directorio raíz, pertenecen cada uno a un usuario distinto. Dos de estos usuarios han creado subdirectorios 
para proyectos en los que están trabajando. 

5.2.2 Nombres de ruta 

Cuando el sistema de archivos se organiza en forma de árbol de directorios, se necesita) método para 
especificar los nombres de los archivos. Hay dos métodos diferentes en uso con el primero, se asigna a 
cada archivo un nombre de ruta absoluto que consiste en la ruta desde el directorio raíz hasta el archivo. 
Por ejemplo, la ruta /usr/ast/mailbox indica que el directorio raíz contiene un subdirectorio usr, que a su 
vez contiene un subdirectorio así, el cual con ne el archivo mailbox. Los nombres de ruta absolutos 
siempre parten del directorio raíz y los únicos. En UNIX los componentes de la ruta se separan con /. En 
MS-DOS el separador es 1;) MULTICS es >. Sea cual sea el carácter empleado, si el primer carácter del 
nombre de rutas es el separador, la ruta es absoluta. 

El otro tipo de nombre es el nombre de ruta relativo, el cual se utiliza en combinación con el 
concepto de directorio de trabajo (también llamado directorio actual). Un usuario puede de un directorio 
como directorio de trabajo actual, en cuyo caso todos los nombres de archivo que comiencen en el 
directorio raíz se tomarán en relación con el directorio con el trabajo. Por eje si el directorio de trabajo 
actual es /usr/ast, entonces se podrá hacer referencia al archivo cuya ruta 
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absoluta es /usr/ast/mailbox simplemente como mailbox. En otras palabras, el comando de UNIX 
cp/usr/ast/mailbox/usr/ast/mailbox.bat 
y el comando 
cp mailbox mailbox.bak 

harán exactamente lo mismo si el directorio de trabajo es /usr/ast. La forma relativa suele ser más cómoda, 
pero hace lo mismo que la forma absoluta. 

Algunos programas necesitan acceder a un archivo específico sin considerar el directorio de 
trabajo. En tal caso, siempre deben usar nombres de ruta absolutos. Por ejemplo, un revisor ortográfico 
podría necesitar leer /usr/lib/dictionary para efectuar su trabajo. En este caso, el programa deberá usar el 
nombre de ruta absoluto completo porque no sabe cuál será el directorio de trabajo cuando sea invocado. 
El nombre de ruta absoluta siempre funciona, sea cual sea el directorio de trabajo. 

Desde luego, si el revisor de ortografía necesita un gran número de archivos de /usr/lib, una 
estrategia alternativa es que emita una llamada al sistema para cambiar su directorio de trabajo a /usr/lib, y 
luego utilice sólo dictionary como primer parámetro de open. Al cambiar explícitamente su directorio de 
trabajo, el programa sabe con certeza en qué lugar del árbol de directorios está, y puede usar rutas 
relativas. 

En la mayor parte de los sistemas, cada proceso tiene su propio directorio de trabajo, así que 
cuando un proceso cambia su directorio de trabajo y luego sale, ningún otro proceso resulta afectado y no 
quedan rastros del cambio en el sistema de archivos. De esta forma, un proceso siempre puede cambiar sin 
peligro su directorio de trabajo cada vez que le resulte cómodo hacerlo. Por otro lado, si un procedimiento 
de biblioteca cambia el directorio de trabajo y al terminar no lo cambia otra vez al que estaba vigente 
antes, es posible que el resto del programa no funcione, ya que ahora podría estar en un directorio distinto 
del que cree que está. Por esta razón, los procedimientos de biblioteca casi nunca cambian el directorio de 
trabajo y, cuando necesitan hacerlo, siempre lo restauran antes de regresar. 

La mayor parte de los sistemas operativos que manejan un sistema de directorios jerárquico tiene 
dos entradas especiales en cada directorio, y generalmente pronunciados "punto" y "punto punto". 
Punto se refiere al directorio actual; punto punto se refiere a su padre. Para ver cómo se utilizan éstos, 
consideremos el árbol de archivos UNIX de la Fig. 5-7. Cierto proceso tiene /us r/ast como directorio de 
trabajo, y puede usar .. para subir por el árbol. Por ejemplo, el proceso en cuestión puede copiar el archivo 
/usr/lib/dictionary en su propio directorio empleando el comando de shell 
cp ../lib/dictionary . 

La primera ruta hace que el sistema que suba (al directorio usr) y luego baje al directorio lib para 
encontrar el archivo dictionary. 

El segundo argumento indica el directorio actual. Cuando proporcionamos al comando cp un 
nombre de directorio (incluido punto) como último argumento, copia todos los archivos ahí. Desde luego, 
una forma más normal de efectuar el copiado sería escribir 
¡ cp /usr/lib/dictionary. 
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Aquí el empleo de punto ahorra al usuario el trabajo de escribir dictionary otra vez. 

5.2.3 Operaciones con directorios 

Las llamadas al sistema permitidas para administrar directorios muestran variaciones más amp. de un 
sistema a otro que las llamadas para archivos. A fin de dar una idea de la naturaleza modo de operar de 
esas llamadas, presentaremos una muestra (tomada de UNIX). 

1. CRÉATE. Se crea un directorio, que está vacío con la excepción de punto y punto, punto, que el 
sistema (o, en unos pocos casos, el programa mkdir) coloca ahí automáticamente. 

2. DELETE. Se elimina un directorio. Sólo puede eliminarse un directorio vacío. Un directorio 
que sólo contiene punto y punto punto se considera vacío, ya que éstos normalmente no pueden 
eliminarse. 

3. OPENDIR. Los directorios pueden leerse. Por ejemplo, para listar todos los archivo de un 
directorio, un programa para emitir listados abre el directorio y lee los nombres 
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de los archivos que contiene. Antes de poder leer un directorio, es preciso abrirlo, de forma análoga a 
como se abren y leen los archivos. 

4. CLOSEDIR. Una vez que se ha leído un directorio, debe cerrarse para liberar espacio de tablas 
intemas. 

5. READDIR. Esta llamada devuelve la siguiente entrada de un directorio abierto. Antes, era 
posible leer directorios empleando la llamada al sistema READ normal, pero ese enfoque tiene la 
desventaja de obligar al programador a conocer y manejar la estructura intema de los directorios. En 
contraste, READDIR siempre devuelve una entrada en un formato estándar, sin importar cuál de las 
posibles estructuras de directorio se esté usando. 

6. RENAME. En muchos sentidos, los directorios son iguales que los archivos y podemos cambiar 
su nombre tal como hacemos con los archivos. 

7. LINK. El enlace (linking) es una técnica que permite a un archivo aparecer en más de un 
directorio. Esta llamada al sistema especifica un archivo existente y un nombre de ruta, y crea un enlace 
del archivo existente al nombre especificado por la ruta. De este modo, el mismo archivo puede aparecer 
en múltiples directorios. 

8. UNLINK. Se elimina una entrada de directorio. Si el archivo que está siendo desvinculado sólo 
está presente en un directorio (el caso normal), se eli min ará del sistema de archivos. Si el archivo está 
presente en varios directorios, sólo se eliminará el nombre de ruta especificado; los demás seguirán 
existiendo. En UNIX, la llamada al sistema para eliminar archivos (que ya vimos antes) es, de hecho, 
UNLINK. 

La lista anterior incluye las llamadas más importantes, pero hay otras, por ejemplo, para administrar la 
información de protección asociada con un directorio. 

5.3 IMPLEMENTACIÓN DE SISTEMAS DE ARCHIVOS 

Ya es momento de pasar de la perspectiva del usuario del sistema de archivos a la perspectiva del 
implementador. A los usuarios les interesa la forma de nombrar los archivos, las operaciones que pueden 
efectuarse con ellos, el aspecto que tiene el árbol de directorios y cuestiones de interfaz por el estilo. A los 
implementadores les interesa cómo están almacenados los archivos y directorios, cómo se administra el 
espacio en disco y cómo puede hacerse que todo funcione de forma eficiente y confiable. En las secciones 
siguientes examinaremos varias de estas áreas para conocer los problemas y las concesiones. 

5.3.1 Implementación de archivos 

Tal vez el aspecto más importante de la implementación del almacenamiento en archivos sea poder 
relacionar bloques de disco con archivos. Se emplean diversos métodos en los diferentes sistemas 
operativos. En esta sección examinaremos algunos de ellos. 
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Asignación contigua 

El esquema de asignación más sencillo es almacenar cada archivo como un bloque contiguo de datos en el 
disco. Así, en un disco con bloques de 1K, a un archivo de 50K se le asignarían 50 bloques consecutivos. 
Este esquema tiene dos ventajas importantes. Primera, la implementación es sencilla porque para saber 
dónde están los bloques de un archivo basta con recordar un número, la dirección en disco del primer 
bloque. Segunda, el rendimiento es excelente porque es posible leer todo el archivo del disco en una sola 
operación. 

Desafortunadamente, la asignación contigua tiene también dos ventajas igualmente importantes. 
Primera, no es factible si no se conoce el tamaño máximo del archivó en el momento en que se crea el 
archivo. Sin esta información, el sistema operativo no sabrá cuánto espacio en disco debe reservar. Sin 
embargo, en los sistemas en los que los archivos deben escribirse de un solo golpe, el método puede 
usarse con gran provecho. 

La segunda desventaja es la fragmentación del disco que resulta de esta política de asignación. Se 
desperdicia espacio que de otra forma podría haberse aprovechado. La compactación del disco suele tener 
un costo prohibitivo, aunque tal vez podría efectuarse de noche cuando el sistema estaría ocioso. 

Asignación por lista enlazada 

El segundo método para almacenar archivos es guardar cada uno como una lista enlazada de bloques de 
disco, como se muestra en la Fig. 5-8. La primera palabra de cada bloque se emplea como apuntador al 
siguiente. El resto del bloque se destina a datos. 


Archivo A 



Bloque 4 7 2 10 12 

físico 


Archivo B 



Bloque 6 3 11 14 

físico 

Figura 5-8. Almacenamiento de un archivo como lisia enlazada de bloques de disco 


A diferencia de la asignación contigua, con este método es posible utilizar todos los bloques. No 
se pierde espacio por fragmentación del disco (excepto por fragmentación intema en el último | 




































SEC. 5.3 


IMPLEMENTACION DE SISTEMAS DE ARCHIVOS 


417 


bloque). Además, basta con que en la entrada de directorio se almacene la dirección en disco del primer 
bloque. El resto del archivo puede encontrarse siguiendo los enlaces. 

Por otro lado, aunque la lectura secuencial de un archivo es sencilla, el acceso aleatorio es 
extremadamente lento. Además, la cantidad de almacenamiento de datos en un bloque ya no es una 
potencia de dos porque el apuntador ocupa unos cuantos bytes. Si bien tener un tamaño peculiar no es 
fatal, resulta menos eficiente porque muchos programas leen y escriben en bloques cuyo tamaño es una 
potencia de dos. 

Asignación por lista enlazada empleando un índice 

Las dos desventajas de la asignación por lista enlazada pueden eliminarse si se toma la palabra de 
apuntador de cada bloque y se le coloca en una tabla o índice en la memoria. La Fig. 5-9 muestra el 
aspecto que la tabla tendría para el ejemplo de la Fig. 5-8. En ambas figuras, tenemos dos archivos. El 
archivo A usa los bloques de disco 4,7,2,10 y 12, en ese orden, y el archivo B usa los bloques de disco 6, 
3, 11 y 14, en ese orden. Si usamos la tabla de la Fig. 5-9, podemos comenzar en el bloque 4 y seguir la 
cadena hasta el final. Lo mismo puede hacerse comenzando en el bloque 6. 


El archivo A comienza aqui 
El archivo B comienza aqui 


Bloque no utilizado 


Figura 5-9. Asignación por lista enlazada empleando una labia en la memoria principal. 


Si se emplea esta organización, todo el bloque está disponible para datos. Además, el acceso 
directo es mucho más fácil. Aunque todavía hay que seguir la cadena para encontrar una distancia dada 
dentro de un archivo, la cadena está por completo en la memoria, y puede seguirse sin tener que consultar 
el disco. Al igual que con el método anterior, basta con guardar un solo entero (el 
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número del bloque inicial) en la entrada de directorio para poder localizar todos los bloques, por más 
grande que sea el archivo. MS-DOS emplea este método para la asignación en disco. 

La desventaja primordial de este método es que toda la tabla debe estar en la memoria todo el 
tiempo para que funcione. En el caso de un disco grande con, digamos, 500 000 bloques de 1K (500M), la 
tabla tendrá 500 000 entradas, cada una de las cuales tendrá que tener un mínimo de 3 bytes. Si se desea 
acelerar las búsquedas, se necesitarán 4 bytes. Así, la tabla ocupará de 1.5 a 2 mcgabytes todo el tiempo, 
dependiendo de si el sistema se optimiza en cuanto al espacio o en cuanto al tiempo. Aunque MS-DOS 
emplea este mecanismo, evita manejar tablas muy grandes empleando bloques grandes (de hasta 32K) en 
los discos de gran tamaño. 

Nodos-i 


Nuestro último método para saber cuáles bloques pertenecen a cuál archivo consiste en asociar a cada 
archivo una pequeña tabla llamada nodo-i (nodo-índice), que lista los atributos y las direcciones en disco 
de los bloques del archivo, como se muestra en la Fig. 5-10 


Nodo-¡ 



Figura 5-10. Un nodo-i. 


Las primeras pocas direcciones de disco se almacenan en el nodo-i mismo, así que en el caso de 
archivos pequeños toda la información está contenida en el nodo-i, que se trae del disco a la memoria 
principal cuando se abre el archivo. En el caso de archivos más grandes, una de las direcciones del nodo-i 
es la dirección de un bloque de disco llamado bloque de indirección sencilla. Este bloque contiene 
direcciones de disco adicionales. Si esto todavía no es suficiente, otra dirección del nodo-i, llamada bloque 
de indirección doble, contiene la dirección de un 
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bloque que contiene una lista de bloques de indirección sencilla. Cada uno de estos bloques de indirección 
sencilla apunta a unos cuantos cientos de bloques de datos. Si ni siquiera con esto basta, se puede usar 
también un bloque de dirección triple. UNIX emplea este esquema. 

5.3.2 Implementación de directorios 

Antes de poder leer un archivo, hay que abrirlo. Cuando se abre un archivo, el sistema operativo usa el 
nombre de ruta proporcionado por el usuario para localizar la entrada de directorio. Esta entrada 
proporciona la in formación necesaria para encontrar los bloques de disco. Dependiendo del sistema, esta 
información puede ser la dirección en disco de todo el archivo (asignación contigua), el número del primer 
bloque (ambos esquemas de lista enlazada) o el número del nodo-i. En todos los casos, la fúnción 
principal del sistema de directorios es transformar el nombre ASCII del archivo en la información 
necesaria para localizar los datos. 

Un problema muy relacionado con el anterior es dónde deben almacenarse los atributos. Una 
posibilidad obvia es almacenarlos directamente en la entrada de directorio. Muchos sistemas hacen 
precisamente esto. En el caso de sistemas que usan nodos-i, otra posibilidad es almacenar los atributos en 
el nodo-i, en lugar de en la entrada de directorio. Como veremos más adelante, este método tiene ciertas 
ventajas respecto a la colocación de los atributos en la entrada de directorio. 

Directorios en CP/M 

Iniciemos nuestro estudio de los directorios con un ejemplo especialmente sencillo, el de CP/M (Golden y 
Pechura, 1986), ilustrado en la Fig. 5-11. En este sistema, sólo hay un directorio, así que todo lo que el 
sistema de archivos tiene que hacer para consultar un nombre de archivo es buscarlo en el único 
directorio. Una vez que encuentra la entrada, también tiene los números de bloque en el disco, ya que 
están almacenados ahí mismo, en la entrada, lo mismo que todos los atributos. Si el archivo ocupa más 
bloques de disco de los que caben en una entrada, se asignan al archivo entradas de directorio adicionales. 


T^t 


Números de bloques de disco 
Código Tipo de archivo Alcance Cuenta 
de usuario [extensión) de bloques 


Figura 5-11. Entrada de directorio que contiene los números de bloque de disco para cada archivo. 


Los campos de la Fig. 5-11 tienen los siguientes significados. El campo de código de usuario 
indica qué usuario es el propietario del archivo. Durante una búsqueda, sólo se examinan las entradas que 
pertenecen al usuario que está actualmente en sesión. Los siguientes dos campos dan el nombre y la 
extensión del archivo. El campo alcance (extent) es necesario porque un archivo 
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con más de 16 bloques ocupa múltiples entradas de directorio. Este campo sirve para saber cuál entrada es 
primero, cuál segunda, etc. El campo de cuenta de bloques indica cuántas de las 16 posibles entradas de 
bloque se están usando. Los últimos 16 campos contienen los números de bloque de disco mismos. Es 
posible que el último bloque no esté lleno, así que el sistema no tiene forma de conocer el tamaño exacto 
de un archivo hasta el último byte (es decir, registra los tamaños de archivo en bloques, no en bytes). 

Directorios en MS-DOS 

Consideremos ahora algunos ejemplos de sistemas con árboles de directorios jerárquicos. La Fig. 5-12 
muestra una entrada de directorio de MS-DOS, la cual tiene 32 bytes de longitud y contiene el nombre de 
archivo, los atributos y el número del primer bloque de disco. El primer número de bloque se emplea 
como índice de una tabla del tipo de la de la Fig. 5-9. Siguiendo la cadena, se pueden encontrar todos los 
bloques. 


Bytes 8 3 1 10 2 2 2 4 

Tamaño 

! V \ 

Extensión Atributos Reservado Hora Fecha Primer número 
de Moque 

Figura 5*12. La entrada de directorio de MS-DOS. 



En MS-DOS, los directorios pueden contener otros directorios, dando lugar a un sistema de 
archivos jerárquico. En este sistema operativo es común que los diferentes programas de aplicación 
comiencen por crear un directorio en el directorio raíz y pongan ahí todos sus archivos, con objeto de que 
no haya conflictos entre las aplicaciones. 

Directorios en UNIX 

La estructura de directorios que se usa tradicionalmente en UNIX es en extremo sencilla, como se aprecia 
en la Fig. 5-13. Cada entrada contiene sólo un nombre de archivo y su número de nodo-i. Toda la 
información acerca del tipo, tamaño, tiempos, propietario y bloques de disco está contenida en el nodo-i. 
Algunos sistemas UNIX tienen una organización distinta, pero en todos los casos una entrada de directorio 
contiene en última instancia sólo una cadena ASCII y un número de nodo-i. 

Cuando se abre un archivo, el sistema de archivos debe tomar el nombre que se le proporciona y 
localizar sus bloques de disco. Consideremos cómo se busca el nombre de ruta /usr/ast/mbox. Usaremos 
UNIX como ejemplo, pero el algoritmo es básicamente el mismo para todos los sistemas de directorios 
jerárquicos. Lo primero que hace el sistema de archivos es localizará directorio raíz. En UNIX su nodo-i 
está situado en un lugar fijo del disco. 

A continuación, el sistema de archivos busca el primer componente de la ruta, usr, en el directorio 
raíz para encontrar el número de nodo-i del archivo /usr. La localización de un nodo-itj 
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Bytes 2_14_ 

Nombre de archivo 

T- 

Número de nodo-i 

Figura 5-13. Una entrada de directorio UNIX. 


una vez que se tiene su número es directa, ya que cada uno tiene una posición fija en el disco. Con la 
ayuda de este nodo-i, el sistema localiza el directorio correspondiente a./usr y busca el siguiente 
componente, ast, en él. Una vez que el sistema encuentra la entrada para ast, obtiene el nodo-i del 
directorio /usr/ast. Con este nodo, el sistema puede encontrar el directorio mismo y buscar mbox. 

A continuación se trae a la memoria el nodo-i de este archivo y se mantiene ahí hasta que se cierra el 
archivo. El proceso de búsqueda se ilustra en la F'g. 5-14. 


tamaño 

tiempos 


La búsqueda 
de usr produce 
ei nodo-i 6 


El bloque 132 
es el direc¬ 
torio /usr 


El nodo-i 26 
es para 
/usr/ast 


Modo 

tamaño 

tiempos 


El nodo-i 26 
dice que 
/usr/ast está 
en el bloque 


El bloque 406 
es el direc¬ 
torio /usr/ast 


26 


6 


64 

grants 

92 

books 

60 

mbox 

81 

mlmx 

17 

src 


Figura 5-14. Pasos para buscar /usr/ast/mbox. 


Los nombres de ruta relativos se buscan de la misma forma que los absolutos, sólo que el punto de 
partida es el directorio de trabajo en lugar del directorio raíz. Cada directorio tiene entradas para . y .., que 
se colocan ahí cuando se crea el directorio. La entrada . tiene el número de nodo-i del directorio actual, y 
la entrada .. tiene el número de nodo-i del directorio padre. Así, un procedimiento que busque 
../dick/prog.c simplemente buscará., en el directorio de trabajo, encontrará el número de nodo-i de su 
directorio padre y buscará dick en ese directorio. No se requiere ningún mecanismo especial para manejar 
estos nombres. En lo que al sistema de directorios concierne, se trata de cadenas ASCII ordinarias, lo 
mismo que los demás nombres. 
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5.3.3 Administración del espacio en disco 

Los archivos normalmente se almacenan en disco, así que la administración del espacio en disco es de 
interés primordial para los diseñadores de sistemas de archivos. Hay dos posibles estrategias para 
almacenar un archivo de n bytes: asignar n bytes consecutivos de espacio en disco, o dividir el archivo en 
varios bloques (no necesariamente) contiguos. Un trueque similar (entre segmentación pura y paginación) 
está presente en los sistemas de administración de memoria. 

El almacenamiento de un archivo como secuencia contigua de bytes tiene el problema obvio de 
que, si el archivo crece, probablemente tendrá que pasarse a otro lugar del disco. El mismo problema 
ocurre con los segmentos en la memoria, excepto que el traslado de un segmento en la memoria es una 
operación relativamente rápida comparada con el traslado de un archivo de una posición en el disco a otra. 
Por esta razón, casi todos los sistemas de archivos dividen los archivos en bloques de tamaño fijo que no 
necesitan estar adyacentes. 

Tamaño de bloque 

Una vez que se ha decidido almacenar archivos en bloques de tamaño fijo, surge la pregunta de qué 
tamaño deben tener los bloques. Dada la forma como están organizados los discos, el sector, la pista y el 
cilindro son candidatos obvios para utilizarse como unidad de asignación. En un sistema con paginación, 
el tamaño de página también es un contendiente importante. 

Tener una unidad de asignación grande, como un cilindro, implica que cada archivo, incluso un 
archivo de un byte, ocupará todo un cilindro. Estudios realizados (Mullender y Tanenbaum, 1984) han 
demostrado que la mediana del tamaño de los archivos en los entornos UNIX es de alrededor de 1K, así 
que asignar un cilindro de 32K a cada archivo implicaría un desperdicio de 31/32 = 97% del espacio en 
disco total. Por otro lado, el empleo de una unidad de asignación pequeña implica que cada archivo 
consistirá en muchos bloques. La lectura de cada bloque normalmente requiere una búsqueda y un retardo 
rotacional, así que la lectura de un archivo que consta de muchos bloques pequeños será lenta. 

Por ejemplo, consideremos un disco con 32 768 bytes por pista, tiempo de rotación de 16.67 ms y 
tiempo de búsqueda medio de 30 ms. El tiempo en milisegundos requerido para leer un bloque de k bytes 
es la suma de los tiempos de búsqueda, retardo rotacional y transferencia: 

30 +8.3+ (k/32768)x 16.67 

La curva continua de la Fig. 5-15 muestra la tasa de datos para un disco con estas características en 
fúnción del tamaño de bloque. Si utilizamos el supuesto burdo de que todos los bloques son de 1K (la 
mediana de tamaño medida), la curva de guiones de la Fig. 5-15 indicará la eficiencia de espacio del disco. 
La mala noticia es que una buena utilización del espacio (tamaño de bloque < 2K) implica tasas de datos 
bajas y viceversa. La eficiencia de tiempo y la eficiencia de espacio están inherentemente en conflicto. 

El término medio usual es escoger un tamaño de bloque de 512, 1K o 2K bytes. Si se escoge un 
tamaño de bloque de 1K en un disco cuyos sectores son de 512 bytes, el sistema de archivos siempre leerá 
o escribirá dos sectores consecutivos y los tratará como una sola unidad, indivisi- 
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Tamaño de bloque 


Figura 5-15. La cuna continua (escala de la izquierda) da la tasa de datos de un disco. La 
curva de guiones (escala de la derecha) da la eficiencia de espacio de disco. Todos los archivos 
sonde IK. 


ble. Sea cual sea la decisión que se tome, probablemente convendrá reevaluarla periódicamente, ya que, al 
igual que sucede con todos los aspectos de la tecnología de computadoras, los usuarios aprovechan los 
recursos más abundantes exigiendo todavía más. Un administrador de sistema informa que el tamaño 
medio de los archivos en el sistema universitario que administra ha crecido lentamente con el paso de los 
años, y que en 1997 el tamaño medio de los archivos ha crecido a 12K para los estudiantes y 15K para los 
profesores. 

Administración de bloques libres 

Una vez que se ha escogido el tamaño de bloque, el siguiente problema es cómo seguir la pista a los 
bloques libres. Se utilizan ampliamente dos métodos, mismos que se ilustran en la Fig. 5-16. El primero 
consiste en usar una lista enlazada de bloques de disco, en la que cada bloque contiene tantos números de 
bloques de disco libres como quepan en él. Con bloques de 1K y números de bloque de 32 bits, cada 
bloque de la lista libre contiene los números de 255 bloques libres. (Se requiere una ranura para el 
apuntador al siguiente bloque.) Un disco de 200M necesita una lista libre de, como máximo, 804 bloques 
para contener los 200K números de bloque. Es común que se usen bloques libres para contener la lista 
libre. 

La otra técnica de administración del espacio libre es el mapa de bits. Un disco con n bloques 
requiere un mapa de bits con n bits. Los bloques libres se representan con unos en el mapa, y los bloques 
asignados con ceros (o viceversa). Un disco de 200M requiere 200K bits para el mapa, mismos que 
ocupan sólo 25 bloques. No es sorprendente que el mapa de bits requiera menos espacio, ya que sólo usa 
un bit por bloque, en vez de 32 como en el modelo de lista enlazada. Sólo si el disco está casi lleno el 
esquema de lista enlazada requerirá menos bloques que el mapa de bits. 

Si hay suficiente memoria principal para contener el mapa de bits, este método generalmente es 
preferible. En cambio, si sólo se puede dedicar un bloque de memoria para seguir la pista a los bloques de 
disco libres, y el disco está casi lleno, la lista enlazada podría ser mejor. Con sólo un bloque del mapa de 
bits en la memoria, podría ser imposible encontrar bloques libres en él, causando accesos a disco para leer 
el resto del mapa de bits. Cuando un bloque nuevo de la lista enlazada se carga en la memoria, es posible 
asignar 255 bloques de disco antes de tener que traer del disco el siguiente bloque de la lista. 
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Bloques de disco libres: 16,17, 18 



10011011011011» 


0110110111110111 


10101101101101») 


0110110110111011 


11011010100011T1 


0000111011010111 


1011101101101111 


1100100011101111 


01110111011101H 


Un bloque de risco de 1K puede contener 
256 números de bloque de 32 bits 


Figura 5-16. (a) Almacenamiento de la lista libre en una lista enlazada, (b) Mapa de bits. 


5.3.4 Confiabilidad del sistema de archivos 

La destrucción de un sistema de archivos suele ser un desastre mucho peor que la destrucción una 
computadora. Si una computadora se destruye por un incendio, picos de descarga eléctrica o una taza de 
café vertida sobre el teclado, esto implica una molestia y cuesta dinero, pero generalmente se puede 
adquirir un sustituto con un mínimo de problemas. Las computadoras personales económicas pueden 
reemplazarse en unas cuantas horas con sólo visitar una tienda (excepto las universidades, donde la 
aprobación de una orden de compra requiere tres comités, con firmas y 90 días). 

Si el sistema de archivos de una computadora se pierde irremisiblemente, sea por causa (hardware, 
del software, o ratas que mordisquearon los discos flexibles, la restauración de toda información es difícil, 
tardada y, en muchos casos, imposible. Para las personas cuyos programas, documentos, archivos de 
clientes, registros fiscales, bases de datos, planes de mercadeo otros datos han dejado de existir, las 
consecuencias pueden ser catastróficas. Si bien el sistema archivos no puede ofrecer protección contra la 
destrucción física del equipo y los medios, puede ayudar a proteger la información. En esta sección 
exa mi naremos algunas cuestiones que intervienen en la salvaguarda del sistema de archivos. 

Los discos pueden tener bloques defectuosos, como se apuntó en el capítulo 3. Los discos 
flexibles normalmente son perfectos cuando salen de la fábrica, pero pueden adquirir defectos durante el 
uso. Los discos Winchester con frecuencia tienen bloques defectuosos aun siendo nuevos; simplemente 
cuesta demasiado fabricarlos completamente libres de todo defecto. De hecho, antes los discos duros 
solían entregarse con una lista de los bloques defectuosos descu- 
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tuertos por las pruebas del fabricante. En tales discos se reserva un sector para contener una lista de 
bloques defectuosos. Cuando se inicializa originalmente el controlador en hardware, éste lee la lista de 
bloques defectuosos y escoge un bloque (o una pista) de repuesto para sustituir los defectuosos, 
registrando la correspondencia en la lista de bloques defectuosos. A partir de entonces, todas las 
solicitudes que pidan el bloque defectuoso usarán el de repuesto. Cada vez que se descubren nuevos 
errores se actualiza esta lista como parte de un formato de bajo nivel. 

Ha habido una mejoría constante en las técnicas de fabricación, de modo que los bloques 
defectuosos son menos comunes que antaño; sin embargo, no han desaparecido. El controlador en 
hardware de una unidad de disco moderna es muy complejo, como se vio en el capítulo 3. En estos discos, 
las pistas tienen por lo menos un sector más que el número de sectores necesario, con objeto de que al 
menos un punto defectuoso pueda pasarse por alto dejándolo en un hueco entre dos sectores consecutivos. 
También hay unos cuantos sectores de repuesto en cada cilindro con objeto de que el controlador pueda 
establecer una nueva correspondencia de sectores si se percata de que un sector requiere más de cierto 
número de reintentos para leerse o escribirse. Así, el usuario casi nunca se da cuenta de la existencia de 
bloques defectuosos ni de su administración. No obstante, cuando un disco IDE o SCSI moderno falla, 
casi siempre falla gravemente, porque se ha quedado sin sectores de repuesto. Los discos SCSI informan 
de un "error recuperado" cuando alteran la correspondencia de un bloque. Si el controlador en software se 
da cuenta de esto y exhibe un mensaje en la pantalla, el usuario sabrá que es momento de comprar un 
nuevo disco cuando estos mensajes comiencen a aparecer con frecuencia. 

Existe una solución de software sencilla al problema de los bloques defectuosos, apropiado para 
usarse en los discos menos modernos. La estrategia requiere que el usuario del sistema de archivos 
construya cuidadosamente un archivo que contenga todos los bloques defectuosos. Esta técnica retira 
dichos bloques de la lista libre, así que nunca se usarán para archivos de datos. En tanto nunca se lea ni 
escriba el archivo de bloques defectuosos, no habrá problemas. Se debe tener cuidado durante los 
respaldos de disco para evitar la lectura de este archivo. 

Respaldos 

Incluso teniendo una estrategia ingeniosa para manejar los bloques defectuosos, es importante respaldar 
los archivos con frecuencia. Después de todo, cambiar automáticamente a una pista de repuesto después 
de que se ha arruinado un bloque que contenía datos cruciales es algo parecido a cerrar la puerta de la 
caballeriza después de que ha escapado un valioso caballo de carreras. 

Los sistemas de archivos en disco flexible se pueden respaldar con sólo copiar todo el disco en 
uno en blanco. Los sistemas de archivos en discos Winchester pequeños se pueden respaldar vaciando todo 
el disco en cinta magnética. Entre las tecnologías actuales están los cartuchos de cinta de 150M y las 
cintas Exabyte o DAT de 8G. 

En el caso de Winchester grandes (p. ej., 10GB), el respaldo de toda la unidad en cinta es tedioso y 
tardado. Una estrategia que es fácil de implementar pero desperdicia la mitad del espacio del 
almacenamiento es instalar en cada computadora dos unidades de disco en lugar de una. Ambas unidades 
se dividen en dos mitades: datos y respaldo. Cada noche la porción de datos de la unidad O se copia en la 
porción de respaldo de la unidad 1, y viceversa, como se muestra en la Fig. 5-17. De esta forma, si una 
unidad se arruina por completo, no se perderá información. 
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f igura 5-17. El respaldo de cada unidad en la otra desperdicia la mitad del espacio de almace¬ 
namiento. 


Una alternativa al vaciado diario de todo el sistema de archivos es realizar vaciados increméntales. 
La forma más sencilla de vaciado incremental consiste en efectuar un vaciado completo periódicamente, 
digamos cada semana o cada mes, y realizar un vaciado diario de sólo aquellos archivos que han sido 
modificados después del último vaciado completo. Un esquema mejor sería vaciar sólo aquellos archivos 
que han cambiado desde que se vaciaron por última vez. 

Para implementar este método, se debe mantener en disco una lista de los tiempos de vaciado para 
cada archivo. El programa de vaciado revisa cada archivo del disco. Si un archivo fue modificado después 
de la última vez que se vació, se vacía otra vez y su tiempo de último vaciado se cambia al tiempo actual. 
Si esto se hace en un ciclo mensual, el método requiere 31 cintas de vaciado diarias, una por día, más 
suficientes cintas para contener un vaciado completo, que se efectúa una vez al mes. También se usan 
otros esquemas más complejos que emplean menos cintas. 

También están en uso métodos automáticos que emplean múltiples discos. Por ejemplo, la 
creación de espejos emplea dos discos. Las escrituras se efectúan en ambos discos, y las lecturas 
provienen de uno solo. La escritura en el disco espejo se retrasa un poco, efectuándose cuando el sistema 
está ocioso. Un sistema así puede seguir fúncionando en "modo degradado" si un disco falla, y esto 
permite reemplazar el disco que falló y recuperar los datos sin tener que parar el sistema. 

Consistencia del sistema de archivos 

Otra área en la que la confiabilidad es importante es la consistencia del sistema de archivos. Muchos 
sistemas de archivos leen bloques, los modifican y los vuelven a escribir después. Si el sistema se cae 
antes de que todos los bloques modificados se hayan escrito en disco, el sistema de archivos puede quedar 
en un estado inconsistente. Este problema se vuelve crítico si algunos de los bloques que no se han escrito 
contienen nodos-i, entradas de directorio o la lista libre. 

Para enfrentar el problema de un sistema de archivos inconsistente, la mayor parte de las 
computadoras cuentan con un programa de utilería que verifica la consistencia del sistema de archivos. 
Este programa puede ejecutarse cuando el sistema se arranca, sobre todo después de una caída. La 
descripción que sigue se refiere al fúncionamiento de tal utilería en UNIX y MINIX; otros sistemas tienen 
algo similar. Estos verificadores del sistema de archivos exa mi nan cada sistema de archivos (disco) con 
independencia de los demás. 

Se pueden realizar dos tipos de verificaciones de consistencia: de bloques y de archivos. Para 
comprobar la consistencia de los bloques, el programa construye dos tablas, cada una de las cuales 
contiene un contador para cada bloque, que inicialmente vale 0. Los contadores de la primera 
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tabla llevan la cuenta de cuántas veces un bloque está presente en un archivo; los contadores de la segunda 
tabla registran cuántas veces está presente cada bloque en la lista libre (o en el mapa de bits de bloques 
libres). 

A continuación, el programa lee todos los nodos-i. Partiendo de un nodo-i, es posible construir 
una lista de todos los números de bloque empleados en el archivo correspondiente. Al leerse cada número 
de bloque, su contador en la primera tabla se incrementa. Después, el programa examina la lista o mapa de 
bits de bloques libres, para encontrar todos los bloques que no están en uso. Cada ocurrencia de un bloque 
en la lista libre hace que su contador en la segunda tabla se incremente. 

Si el sistema de archivos es consistente, cada bloque tendrá un 1 ya sea en la primera tabla o en la 
segunda, como se ilustra en la Fig. 5.18(a). Sin embargo, después de una caída las tablas podrían tener el 
aspecto de la Fig. 5-18(b), en la que el bloque 2 no ocurre en ninguna de las dos tablas. Este bloque se 
informará como bloque fallante. Aunque los bloques fallantes no representan un daño real, desperdician 
espacio y, por tanto, reducen la capacidad del disco. La solución en el caso de haber bloques fallantes es 
directa: el verificador del sistema de archivos simplemente los agrega a la lista libre. 
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|o|cMolilo|o|o|o|ililo|olo|i|T| 8 k)<>u . t i < Ko» 

(a) 

0123456789 101112131415 

|o|.|.|.|¡|.|(.|.|.l.l,|ifflTP1 aw.»~ 

(C) 


012345678 9101112131415 

MiH.loliMiTiMTr.lóIol » 

loTololonorom^R TTTI^ 

(b> 

0123456789 101112131415 

I i M°N o I 2 1 , 1 i M o 1°1 , J , IíE 3 b> 

|o|o|i|o|ilo|o|olo|iMololoM7| » 

(d) 


Figura 5-18. Estados del sistema de archivos, (a) Consistente, (b) Bloque faltante. (c) Bloque 
duplicado en la lista libre, (d) Bloque de datos duplicado. 


Otra situación que podría ocurrir es la de la Fig. 5-18(c). Aquí vemos un bloque, el número 4, que 
ocurre dos veces en la lista libre. (Sólo puede haber duplicados si la lista libre es realmente una lista; si es 
un mapa de bits esto es imposible.) La solución en este caso también es simple: reconstruir la lista libre. 

Lo peor que puede suceder es que el mismo bloque de datos esté presente en dos o más archivos, 
como se ilustra en la Fig. 5-18(d) con el bloque 5. Si cualquiera de estos archivos se elimina, el bloque 5 
se colocará en la lista libre, dando lugar a una situación en la que el mismo bloque está en uso y libre al 
mismo tiempo. Si se eli mi nan ambos archivos, el bloque se colocará en la lista libre dos veces. 

La acción apropiada para el verificador del sistema de archivos es asignar un bloque libre, 
copiaren él el contenido del bloque 5, e insertar la copia en uno de los archivos. De este modo, el 
contenido de información de los archivos no cambiará (aunque casi con toda seguridad estará 
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revuelto), y la estructura del sistema de archivos al menos será consistente. Se deberá informar del error, 
para que el usuario pueda inspeccionar los daños. 

Además de verificar que cada bloque esté donde debe estar, el verificador del sistema de archivos 
también revisa el sistema de directorios. En este caso también se usa una tabla de contadores, pero ahora 
uno por cada archivo, no por cada bloque. El programa parte del directorio raíz y desciende 
recursivamente el árbol, inspeccionando cada directorio del sistema de archivo; Para cada archivo de cada 
directorio, el verificador incrementa el contador correspondiente i nodo-i de ese archivo (véase en la Fig. 
5-13 la organización de una entrada de directorio). 

Una vez que termina la revisión, el verificador tiene una lista, indizada por número de nodo que 
indica cuántos directorios apuntan a ese nodo-i. Luego, el programa compara estos números con los 
conteos de enlace almacenados en los nodos-i mismos. En un sistema de archivos consistente, ambos 
conteos coinciden. Sin embargo, pueden ocurrir dos tipos de errores: el conteo de enlaces del nodo-i puede 
ser demasiado alto o demasiado bajo. 

Si el conteo de enlaces es mayor que el número de entradas de directorio, entonces aunque si 
borraran todos los archivos de todos los directorios el conteo seguiría siendo mayor que cero y e nodo-i no 
se eliminaría. Este error no es grave, pero desperdicia espacio en el disco con archivo: que no están en 
ningún directorio, así que debe corregirse asignando el valor correcto al conteo de enlaces del nodo-i. 

El otro error puede ser catastrófico. Si dos entradas de directorio están enlazadas a un archivo, 
pero el nodo-i dice que sólo hay una, cuando se elimine cualquiera de las entradas de directorio, el conteo 
del nodo-i se convertirá en cero. Cuando esto suceda, el sistema de archivos le marcará como desocupado 
y liberará todos sus bloques. El resultado de esta acción es que uno de los directorios ahora apunta a un 
nodo-i desocupado, cuyos bloques pronto pueden ser asignados a otros archivos. Una vez más, la solución 
es hacer que el conteo de enlaces del nodo-i sea igual al número real de entradas de directorio. 

Estas dos operaciones, verificar bloques y verificar directorios, a menudo se integran por razones 
de eficiencia (p. ej., sólo se requiere una pasada por los nodos-i). También pueden realizarse otras 
verificaciones heurísticas. Por ejemplo, los directorios tienen un formato definido, con números de nodo-i 
y nombres ASCII. Si un número de nodo-i es mayor que el número de nodos-i que hay en el disco, es 
señal de que el directorio ha sido dañado. 

Además, cada nodo-i tiene un modo, y algunos de estos modos son permitidos pero extraños, 
como el 0007, que no permite que el propietario ni su grupo tengan acceso, pero sí permite a terceros leer, 
escribir y ejecutar el archivo. Podría ser útil al menos informar de la existencia de archivos que dan más 
derechos a terceros que al propietario. Los directorios que tienen más de 1000 entradas también son 
sospechosos. Los archivos situados en directorios de usuarios, pero que son propiedad del superusuario y 
tienen encendido el bit SETUID, implican posibles problemas de seguridad. Con un poco de esfuerzo, es 
posible hacer una lista más o menos larga de situaciones permitidas pero peculiares que valdría la pena 
informar. 

Los párrafos anteriores abordaron el problema de proteger al usuario contra las caídas del sistema. 
Algunos sistemas de archivos también se preocupan por proteger al usuario contra sí mismo. Si la 
intención del usuario era teclear 
rm *.o 
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para eliminar todos los archivos que terminan con .o (archivos objeto generados por el compilador), pero 
accidentalmente teclea (adviértase el espacio después del asterisco), rm eliminará todos los archivos del 
directorio actual y después se quejará de que no puede encontrar a .o. En MS-DOS y algunos otros 
sistemas, cuando un archivo se elimina lo único que sucede es que se enciende un bit en el directorio o 
nodo-i para marcar ese archivo como eliminado. No se devuelven bloques de disco a la lista libre en tanto 
no se necesitan realmente. Por tanto, si el usuario descubre el error de inmediato, es posible ejecutar un 
programa de utilería especial que "deselimina" (es decir, restaura) los archivos eliminados. En 
WINDOWS 95, los archivos eli mi nados se colocan en un directorio de reciclado especial, del cual pueden 
recuperarse posteriormente si es necesario. Desde luego, no se recupera espacio de almacenamiento en 
tanto los archivos no se borran de dicho directorio especial. 

5.3.5 Rendimiento del sistema de archivos 

El acceso a un disco es mucho más lento que el acceso a la memoria. La lectura de una palabra de 
memoria por lo regular toma decenas de nanosegundos. La lectura de un bloque de un disco duro puede 
tardar 50 microsegundos, lo que implica que es cuatro veces más lenta por palabra de 32 bits, pero a esto 
deben sumarse de 10 a 20 milisegundos para mover la cabeza de lectura a la pista correcta y luego esperar 
a que el sector deseado se coloque debajo de la cabeza. Si sólo se necesita una palabra, el acceso a la 
memoria será del orden de 100 000 veces más rápido que al disco. En vista de esta diferencia en el tiempo 
de acceso, muchos sistemas de archivos se han diseñado pensando en reducir el número de accesos a disco 
requeridos. 

La técnica más común empleada para reducir los accesos a disco es el caché de bloques o el 
caché de buffer (la palabra caché proviene del verbo francés cacher, que significa esconder). En este 
contexto, un caché es una colección de bloques que lógicamente pertenecen al disco pero que se están 
manteniendo en la memoria por razones de rendimiento. 

Se pueden usar diversos algoritmos para administrar el caché, pero uno de los más comunes es 
inspeccionar todas las solicitudes de lectura para ver si el bloque requerido está en el caché. Si es así, la 
solicitud de lectura se puede satisfacer sin un acceso'a'disco. Si el bloque no está en el caché, primero se 
lee del disco y se coloca en el caché, y luego se copia al lugar donde se necesita. Las solicitudes 
subsecuentes del mismo bloque se pueden satisfacer desde el caché. 

Si es necesario cargar un bloque en el caché y éste está lleno, es preciso deshacerse de un bloque y 
escribirlo en el disco si ha sido modificado desde que se trajo del disco. Esta situación es muy similar a la 
paginación, y todos los algoritmos de paginación usuales que vimos en el capítulo 4, como FIFO, segunda 
oportunidad y LRU, son aplicables. Una diferencia agradable entre la paginación y el manejo de caché es 
que las referencias al caché son relativamente poco frecuentes, por lo que se hace factible mantener todos 
los bloques en orden LRU exacto empleando listas enlazadas. 

Desafortunadamente, hay un pequeño detalle. Ahora que tenemos una situación en la que es 
posible usar LRU exacto, resulta que este algoritmo es indeseable. El problema tiene que ver con 
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las caídas y la consistencia del sistema de archivos que vimos en la sección anterior. Si un bloque crítico, 
digamos un bloque de nodo-i, se coloca en el caché y se modifica, pero no se reescribe en el disco, una 
caída dejaría al sistema de archivos en un estado inconsistente. Si el bloque de nodo-i se coloca al final de 
la cadena de LRU, puede pasar un buen rato antes de que llegue i principio y se reescriba en el disco. 

Además, a algunos bloques, como los de doble indirección, casi nunca se hace referencia dos 
veces dentro de un tiempo corto. Estas consideraciones dan lugar a un esquema LRU modificado teniendo 
en cuenta dos factores: 

1. ¿Es probable que el bloque se necesite pronto otra vez? 

2. ¿Es indispensable el bloque para la consistencia del sistema de archivos? 

Para poder contestar ambas preguntas, los bloques pueden dividirse en categorías, como bloque de 
nodo-i, bloques de indirección, bloques de directorio, bloques de datos llenos y bloques de datos 
parcialmente llenos. Los bloques que probablemente no se necesitarán pronto otra vez se colocan al frente, 
no al final, de la lista de LRU, con objeto de que sus buffers se reutilice rápidamente. Los bloques que 
podrían necesitarse pronto otra vez, como un bloque parcialmente lleno que se está escribiendo, se colocan 
al final de la lista, para que estén en ella un buen tiempo. 

La segunda pregunta es independiente de la primera. Si el bloque es indispensable para 1 
consistencia del sistema de archivos (básicamente, todo excepto los bloques de datos) y ha sidí 
modificado, se deberá escribir de inmediato en el disco, sin importar en qué extremo de la list LRU se 
coloque. Al escribir los bloques críticos rápidamente, reducimos en buena medida' probabilidad de que 
una caída arruine el sistema de archivos. 

Incluso con esta medida para mantener intacta la integridad del sistema de archivos, no i deseable 
mantener los bloques de datos demasiado tiempo en el caché antes de escribirlos en i disco. Consideremos 
la situación de una persona que está usando una computadora personal para escribir un disco. Incluso si 
nuestro escritor le dice periódicamente al editor que grabe en el disco el archivo que está editando, hay 
una buena probabilidad de que todo estará aún en el caché y nada en el disco. Si el sistema se cae, la 
estructura del sistema de archivos no estará corrompida, pero se habrá perdido todo un día de trabajo. 

No hace falta que ocurra esta situación muchas veces para que tengamos un usuario muy 
descontento. Los sistemas adoptan dos enfoques para manejar el problema. Lo que hace UNIX tener una 
llamada al sistema, SYNC, que obliga la escritura inmediata en disco de todos los bloque modificados. 
Cuando el sistema se inicia, se pone en marcha un programa de segundo plano normalmente llamado 
up date que da vueltas en un ciclo infinito emitiendo llamadas SYNC y durmiendo durante 30 segundos 
entre una llamada y otra. Así, nunca se pierden más de 30 seg a causa se una caída. 

Lo que hace MS-DOS es grabar todos los bloques modificados en el disco tan pronto como 
modifican. Los caches en los que todos los bloques modificados se escriben en el disco de inmediato se 
denominan caches de escritura inmediata de disco que los de otro tipo. La diferencia entre estos dos 
enfoques puede verse cuando una grama escribe un bloque de I K carácter por carácter. UNÍX acumula 
tocios los caracteres en el 
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caché y escribe el bloque en disco una vez cada 30 segundos, o cuando el bloque se quita del caché. MS- 
DOS efectúa un acceso a disco por cada carácter que se escribe. Desde luego, la mayor parte de los 
programas manejan buffers internos, así que normalmente no escriben un carácter, sino una línea o una 
unidad más grande en cada llamada al sistema WRITE. 

Una consecuencia de esta diferencia en la estrategia de caché es que si reinamos un disco 
(flexible) de un sistema UNIX sin efectuar SYNC casi siempre perderemos datos, y en algunos casos 
corromperemos también el sistema de archivos. En MS-DOS no hay problema. Se escogieron estas 
diferentes estrategias porque UNIX se desarrolló en un entorno en el que todos los discos eran duros y no 
removibles, mientras que MS-DOS se inició en el mundo de los disquetes. Al generalizarse el uso de 
discos duros, incluso en las microcomputadoras pequeñas, el enfoque de UNIX, al ser más eficiente, 
definitivamente será el del futuro. 

El uso de caché no es la única forma de aumentar el rendi mi ento de un sistema de archivos. Otra 
técnica importante es reducir la cantidad de movimiento del brazo del disco colocando cerca unos de 
otros, de preferencia en el mismo cilindro, bloques a los que probablemente se accederá en secuencia. 
Cuando se escribe un archivo de salida, el sistema de archivos tiene que asignar los i bloques uno por uno, 
conforme se necesitan. Si los bloques libres están registrados en un mapa j de bits, y el mapa de bits 
completo está en la memoria principal, no es difícil escoger un bloque I libre lo más cercano posible al 
bloque anterior. En el caso de una lista libre, ubicada parcialmente I en disco, es mucho más difícil asignar 
bloques cercanos unos a otros. 

No obstante, incluso con una lista libre, es posible lograr cierto agrupamiento de bloques. El truco 
consiste en seguir la pista al espacio de almacenamiento en disco no por bloques, sino por grupos de 
bloques consecutivos. Si una pista consta de 64 sectores de 512 bytes, el sistema podría usar bloques de 1 
K (dos sectores) pero asignar espacio de almacenamiento en disco en unidades de dos bloques (cuatro 
sectores). Esto no es lo mismo que tener bloques de disco de 2K, ya que el caché seguiría usando bloques 
de 1K y las transferencias de disco también serían de 1K, pero la lectura secuencial de un archivo en un 
sistema que por lo demás está ocioso reduciría el número de búsquedas a la mitad, mejorando 
considerablemente el rendimiento. 

Una variación del mismo tema es tener en cuenta el posicionamiento rotacional. Al asignar pues, 
el sistema intenta colocar bloques consecutivos de un archivo en el mismo cilindro, pero intercalados a fin 
de obtener un rendimiento máximo. Por tanto, si un disco tiene un tiempo de rotación de 16.67 ms y un 
proceso de usuario tarda unos 4 ms para solicitar y obtener un bloque disco, cada bloque deberá colocarse 
al menos un cuarto de giro más allá que su predecesor. 

Otro cuello de botella de rendimiento en los sistemas que usan nodos-i o algo equivalente es 6 la 
lectura de incluso un archivo corto requiere dos accesos a disco: uno para el nodo-i y el o para el bloque. 
En la Fig. 5-19(a) se muestra la colocación usual de los nodos-i. Aquí todos I nodos-i están cerca del 
principio del disco, así que la distancia media entre un nodo-i y sus bloques es cerca de la mitad del 
número de cilindros, lo que implica movimientos largos del brazo. 

Una forma fácil de mejorar el rendimiento es colocar los nodos-i en la parte media del disco, en 
principio, reduciendo así a la mitad el movimiento medio del brazo para desplazarse del *i al primer 
bloque. Otra idea, que se muestra en la Fig. 5-19(b), es dividir el disco en grupos todos, cada uno con sus 
propios nodos-i, bloques y lista libre (McKusick et al., 1984). Al un archivo nuevo se puede escoger 
cualquier nodo-i, pero se intenta encontrar un bloque 
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(a) (b) 

Figura 5-19. (a) Nodos-i colocados al principio del disco, (b) Disco dividido en grupos de 
cilindros, cada uno con sus propios bloques y nodos-i. 


que esté en el mismo grupo de cilindros que el nodo-i. Si no hay uno disponible, se usa un bloque de un 
cilindro cercano. 


5.3.6 Sistemas de archivos estructurados por diario 


Los cambios tecnológicos están ejerciendo presión sobre los sistemas de archivos actuales. En particular, 
las CPU cada vez son más rápidas, los discos cada vez son más grandes y económicos (pero no mucho 
más rápidos), y el tamaño de las memorias está creciendo exponencialmente. El único parámetro que no 
está mejorando a pasos agigantados es el tiempo de búsqueda en disco La combinación de estos factores 
implica que en muchos sistemas de archivos está apareciendo un cuello de botella del rendimiento. 
Investigaciones efectuadas en Berkeley intentaron aliviar este problema diseñando un tipo totalmente 
nuevo de sistema de archivos, LFS (el sistema de archivos estructurado por diario, log-structured file 
system). En esta sección describiremos brevemente cómo funciona LFS. Si el lector desea un tratamiento 
más detallado, puede consultar (Rosenblum y Ousterhout, 1991). 

La idea en que se basa el diseño LFS es que conforme las CPU se hacen más rápidas y las 
memorias RAM se hacen más grandes, los caches de disco están aumentando aceleradamente. En 
consecuencia, ya es posible satisfacer una fracción sustancial de todas las solicitudes de lectura 
directamente del caché del sistema de archivos, sin tener que acceder al disco. De esta observación se 
desprende que, en el futuro, la mayor parte de los accesos a disco serán escrituras, y el mecanismo de 
lectura anticipada que se usa en algunos sistemas de archivos para obtener bloques antes de que se 
necesiten ya no representará una ganancia significativa en cuanto al rendi mi ento. 

Para empeorar las cosas, en la mayor parte de los sistemas de archivos las escrituras se efectúan en 
fragmentos muy pequeños. Las escrituras pequeñas son muy ineficientes, ya que una escritura en disco de 
50 microsegundos típicamente va precedida por una búsqueda de 10 ms y un retardo rotacional de 6 ms. 
Con estos parámetros, la eficiencia del disco decae a una fracción de 1%. 
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A fin de ver de dónde provienen todas estas escrituras pequeñas, consideremos la creación de un 
archivo nuevo en un sistema UNIX. Para escribir este archivo, es preciso escribir el nodo-i del directorio, 
el bloque de directorio, el nodo-i del archivo y el archivo mismo. Si bien estas escrituras podrían diferirse, 
hacerlo expone el sistema de archivos a problemas de consistencia graves en caso de ocurrir una caída 
antes de llevarse a cabo las escrituras. Por esta razón, las escrituras de nodos-i generalmente se efectúan de 
inmediato. 

Siguiendo este razonamiento, los diseñadores de LFS decidieron reimplementar el sistema de 
archivos de UNIX de forma tal que se aprovechara todo el ancho de banda del disco, incluso en casos en 
los que la carga de trabajo consiste en su mayor parte en escrituras aleatorias pequeñas. La idea 
fundamental consiste en estructurar todo el disco como un diario. Periódicamente, y cuando surge una 
necesidad especial, todas las escrituras pendientes que se han ido almacenando en la memoria se juntan y 
se escriben en el disco en forma de un solo segmento contiguo al final del diario. Así, un mismo segmento 
puede contener nodos-i, bloques de directorio y bloques de datos, todos revueltos. Al principio de cada 
segmento hay un resumen del segmento, que indica el contenido del mismo. Si puede hacerse que en 
promedio el segmento ocupe 1 MB, se podrá aprovechar casi todo el ancho de banda del disco. 

En este diseño, siguen existiendo nodos-i y tienen la misma estructura que en UNIX, pero ahora 
están dispersos por todo el diario, en lugar de estar en una posición fija en el disco. No obstante, cuando se 
localiza un nodo-i, la localización de los bloques se efectúa de la forma acostumbrada. Desde luego, ahora 
es mucho más difícil encontrar un nodo-i, ya que su dirección no se puede calcular simplemente a partir de 
su número, como en UNIX. Para poder encontrar los nodos-i, se mantiene un mapa de ellos, indizado por 
número de nodo-i. La entrada i de este mapa apunta al nodo-i ¿ en el disco. El mapa se mantiene en disco, 
pero también en caché, así que las partes de uso más intenso están en la memoria casi todo el tiempo. 

Resumiendo lo que hemos dicho hasta aquí, todas las escrituras se colocan inicialmente en 
bufffers en la memoria, y periódicamente se escriben en el disco en un solo segmento, al final del diario. 
Cuando se desea abrir un archivo, se utiliza el mapa para encontrar el nodo-i de ese archivo. Una vez 
localizado este nodo, se pueden obtener de él las direcciones de los bloques. Todos los bloques mismos 
están en segmentos en algún lugar del diario. 

Si los discos fúeran infinitamente grandes, la descripción anterior ya lo habría dicho todo. Sin 
embargo, los discos reales son finitos, y tarde o temprano el diario ocupará todo el disco, y ya no será 
posible escribir más segmentos en el diario. Por fortuna, es posible que muchos segmentos existentes 
tengan bloques que ya no se necesitan. Por ejemplo, si se sobreescribe un archivo, su nodo -i apuntará 
ahora a los nuevos bloques, pero los antiguos todavía estarán ocupando espacio en segmentos previamente 
escritos. 

A fin de resolver estos dos problemas, LFS cuenta con un hilo limpiador que dedica su tiempo a 
explorar circularmente el diario y compactarlo. Lo primero que hace el hilo es leer el resumen del primer 
segmento del diario para ver qué nodos-i y archivos contiene. Luego examina el mapa de nodos-i actual 
para ver si los nodos-i todavía están vigentes y si los bloques de archivo todavía están en uso. Si no es así, 
la información correspondiente se desecha. Los nodos-i y bloques que todavía están en uso se pasan a la 
memoria para ser escritos en el siguiente segmento. A Continuación, el segmento original se marca como 
libre a fin de que el diario pueda usarlo para 
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datos nuevos. De esta forma, el limpiador avanza por el diario, eliminando segmentos antiguos de la parte 
de atrás y colocando cualesquier datos aún vigentes que encuentre en la memoria para ser reescritos en el 
siguiente segmento. Así, el disco es un gran buffer circular, con el hilo escritor agregando nuevos 
segmentos al frente y el hilo limpiador quitando los viejos de la parte de atrás. 

La contabilización aquí no es trivial, ya que cuando un bloque de archivo se escribe en un nuevo 
segmento es preciso localizar el nodo-i del archivo (en algún lugar del diario), actualizarlo y colocarlo en 
la memoria para escribirlo en el siguiente segmento. Después, debe actualizarse el mapa de nodos-i de 
modo que apunte a la nueva copia. No obstante, toda esta administración es factible, y los resultados de 
rendimiento demuestran que la complejidad vale la pena. Las mediciones que se presentan en los artículos 
antes citados indican que LFS tiene un rendimiento mejor en un orden de magnitud que el de UNIX 
cuando las escrituras son pequeñas, y un rendi mi ento igual o mejor que el de UNIX en el caso de 
escrituras grandes y lecturas. 


5.4 SEGURIDAD 


Los sistemas de archivos a menudo contienen información que es muy valiosa para sus usuarios. Por 
tanto, la protección de esta información contra el uso no autorizado es una fúnción importante de todos los 
sistemas de archivos. En las siguientes secciones examinaremos diversos problemas relacionados con la 
seguridad y la protección. Estas cuestiones se aplican tanto a los sistemas tiempo compartido como a las 
redes de computadoras personales conectadas a servidores compartidos a través de redes de área local. 


5.4.1 El entorno de seguridad 


Los términos "seguridad" y "protección" con frecuencia se usan indistintamente. No obstante, suele ser 
útil hacer una distinción entre los problemas generales que debemos resolver para asegurar que los 
archivos no sean leídos ni modificados por personas no autorizadas, lo que incluye cuestiones técnicas, 
gerenciales, legales y políticas, por un lado, y los mecanismos específicos del sistema operativo que 
proporcionan seguridad, por el otro. A fin de evitar confúsiones, usaremos el término seguridad para 
referimos al problema global, y el término mecanismos de protección para referimos a los mecanismos 
específicos del sistema operativo que sirven para salvaguardar la información en la computadora. Sin 
embargo, la frontera entre las dos cosas no está bien definida. Primero examinaremos la seguridad; más 
adelante nos ocuparemos de la protección. 

La seguridad tiene muchas facetas. Dos de las más importantes son la pérdida de datos y los 
intrusos. Algunas de las causas comunes de la pérdida de datos son: ,| 

1. Actos divinos: incendios, inundaciones, terremotos, guerras, motines o ratas que mordisquean 
cintas o disquetes. 

2. Errores de hardware o software: fallas de CPU, discos o cintas ilegibles, errores de 
telecomunicación, errores en programas. 

3. Errores humanos: captura incorrecta de datos, montar la cinta o disco equivocado, 
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ejecutar un programa indebido, perder un disco o una cinta, o alguna otra equivocación. 


La mayor parte de estos problemas puede superarse manteniendo respaldos adecuados, de preferencia 
lejos de los datos originales. 

Un problema más interesante es qué hacer respecto a los intrusos. Hay dos clases de estos 
especímenes. Los intrusos pasivos sólo desean leer archivos que no están autorizados para leer. Los 
intrusos activos tienen peores intenciones: quieren efectuar cambios no autorizados a los datos. Al diseñar 
un sistema de modo que sea seguro frente a los intrusos, es importante tener presente la clase de intruso 
contra la que se está tratando de proteger el sistema. He aquí algunas categorías comunes: 

1. Curioseo casual por parte de usuarios no técnicos. Muchas personas tienen en su escritorio 
ter mi n a les conectadas a sistemas de tiempo compartido o computadoras personales conectadas a redes y, 
al ser la naturaleza humana como es, algunas de ellas leerán el correo electrónico y otros archivos de otras 
personas si no se les ponen barreras. En la mayor parte de los sistemas UNIX, por ejemplo, todos los 
archivos están abiertos al público por omisión. 

2. Intromisión por parte de gente de adentro. Los estudiantes, programadores de sistemas, 
operadores y demás personal técnico con frecuencia consideran como un reto personal violar la seguridad 
del sistema de computadora local. Es común que estas personas estén altamente capacitadas y dispuestas a 
dedicar una cantidad sustancial de tiempo a esta labor. 

3. Intento decidido por hacer dinero. Algunos programadores bancarios han intentado introducirse 
en un sistema bancario para robar. Los ardides han variado desde modificar el software para truncar en 
lugar de redondear los intereses, guardándose la fracción de centavo para sí, hasta extraer fondos de 
cuentas que no se han usado en varios años, hasta chantaje ("Páguenme o destruiré todos los registros del 
banco"). 

4. Espionaje comercial o militar. Por espionaje se entiende el intento serio y bien financiado, por 
parte de un competidor o un país extranjero, por robar programas, secretos comerciales, patentes, 
tecnología, diseños de circuitos, planes de marketing, etc. En muchos casos este intento implica 
intervención de líneas o incluso erigir antenas dirigidas hacia la computadora a fin de captar su radiación 
electromagnética. 


Debe ser obvio que tratar de evitar que un gobierno extranjero hostil robe secretos militares es una 
cuestión muy diferente a tratar de impedir que los estudiantes inserten un "mensaje del día" humorístico en 
el sistema. La cantidad de esfuerzo que se invierta en la seguridad y la protección naturalmente dependerá 
de quién se piensa que es el enemigo. 

Otro aspecto del problema de la seguridad es la confidencialidad: proteger a los usuarios contra el uso 
indebido de la información referente a ellos. Aquí intervienen muchas cuestiones legales y morales. ¿Se 
justifica que el gobierno compile expedientes de todo mundo con el objeto de atrapar a quienes no 
cumplen con sus impuestos u otras obligaciones? ¿Necesita la policía 
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poder consultar cualquier dato sobre cualquier persona para poner un alto al crimen organizado?¿Tienen 
derechos los patrones y las compañías de seguros? ¿Qué sucede cuando estos derechos chocan contra los 
derechos individuales? Todas estas cuestiones son extremadamente importantes pero rebasan el alcance 
del presente libro. 


5.4.2 Fallas de seguridad famosas 


Así como la industria del transporte tiene el Titanic y el Hindenburg, los expertos en seguridad de 
computadoras tienen algunas cosas que preferirían olvidar. En esta sección examinaremos algunos 
problemas de seguridad interesantes que han ocurrido en tres sistemas operativos distintos: UNIX, 
TENEX y os/360. 

La utilería de UNIX Ipr, que imprime un archivo en la impresora de líneas, tiene una opción para 
eli mi nar el archivo una vez que se ha impreso. En las primeras versiones de UNIX cualquiera podía usar 
Ipr para imprimir el archivo de contraseñas y luego hacer que el sistema lo eliminara. 

Otra forma de introducirse en UNIX era enlazar un archivo llamado core situado en el directorio 
de trabajo con el archivo de contraseñas. A continuación, el intruso forzaba un vaciado de núcleo de un 
programa SETUID, mismo que el sistema escribía en el archivo core, esto es, encima del archivo de 
contraseñas. De este modo, un usuario podía reemplazar el archivo de contraseñas por uno que contenía 
unas cuantas cadenas escogidas por él (p. ej., argumentos de comandos). 

Otro defecto sutil de UNIX tenía que ver con el comando 


mkdir foo 


Mkdir, que era un programa SETUID propiedad de la raíz, primero creaba el nodo-i para el directorio foo 
con la llamada al sistema MKNOD y luego cambiaba (con la llamada CHOWN) el propietario de foo de 
su uid efectivo (esto es, la raíz) a su uid real (el uid del usuario). Si el sistema era lento, a veces el usuario 
podía eli mi nar rápidamente el nodo-i del directorio y crear un enlace con el archivo de contraseñas bajo el 
nombre foo después de la llamada MKNOD pero antes de CHOWN. Cuando mkdir ejecutaba CHOWN, 
convertía al usuario en propietario del archivo de contraseñas. Si se colocaban los comandos necesarios en 
un guión de shell, se podían intentar una y otra vez hasta que el truco funcionara. 

El sistema operativo TENEX solía ser muy popular en las computadoras DEC-10. Este sistema ya 
no se usa, pero vivirá eternamente en los anales de la seguridad de computadoras gracias al siguiente error 
de diseño. TENEX apoyaba la paginación. Con objeto de que los usuarios pudieran vigilar el 
comportamiento de sus programas, era posible ordenar al sistema que invocara una función de usuario 
cada vez que ocurriera una falla de página. 

TENEX también usaba contraseñas para proteger los archivos. Cuando un programa quería 
acceder a un archivo, tenía que presentar la contraseña apropiada. El sistema operativo verificaba las 
contraseñas carácter por carácter, deteniéndose tan pronto como se daba cuenta de que la contraseña no 
era la correcta. Para introducirse en TENEX, un intruso colocaba cuidadosamente una contraseña como se 
muestra en la Fig. 5-20(a), con el primer carácter al final de una página y el resto al principio de la 
siguiente página. 
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- Frontera de página 


(•) (b) 

Figura 5-20. El problema de contraseña TENEX. 


El siguiente paso era asegurarse de que la siguiente página no estuviera en la memoria. Esto se 
hacía, por ejemplo, haciendo referencia a tantas páginas que la segunda página tenía que ser desalojada 
para que aquéllas pudieran caber. Ahora el programa trataba de abrir el archivo de la víctima, usando la 
contraseña cuidadosamente alineada. Si el primer carácter de la contraseña real era distinto de A, el 
sistema dejaba de verificarla en el primer carácter y regresaba con un mensaje de ILLEGAL PASSWORD 
(contraseña no válida). En cambio, si la contraseña real comenzaba con A, el sistema seguía leyendo y 
generaba una falla de página, de lo cual se informaba al intruso. 

Si la contraseña no comenzaba con A, el intruso cambiaba la contraseña a la de la Fig. 5-20(b) y 
repetía todo el proceso para ver si comenzaba con B. Se requerían como máximo 128 intentos para probar 
todo el conjunto de caracteres ASCII y así determinar el primer carácter. 

Supongamos que el primer carácter era F. La disposición de memoria de la Fig. 5-20(c) permitía 
al intruso probar cadenas de la forma FA, FB, etc. Con esta estrategia, se requerían como mucho 128n 
intentos para adivinar una contraseña ASCII de n caracteres, en lugar de 128". 

Nuestro último ejemplo de defecto se refiere a os/360. La descripción que sigue se ha simplificado 
un poco pero conserva la esencia del defecto. En este sistema era posible iniciar una lectura de cinta y 
luego seguir realizando cálculos mi entras la unidad de cinta transfería datos al espacio del usuario. El 
truco aquí consistía en iniciar con cuidado una lectura de cinta y luego efectuar una llamada al sistema que 
requería una estructura de datos de usuario, por ejemplo, un retuvo para leer y su contraseña. 

Lo primero que hacía el sistema operativo era verificar que la contraseña fuera la correcta ira el archivo 
especificado, y luego regresaba y leía el nombre del archivo otra vez para efectuar el acceso real (podía 
haber guardado el nombre internamente, pero no lo hacía). Desafortunadamente, justo antes de que el 
sistema tratara de obtener el nombre del archivo por segunda vez, la unidad de cinta lo sobreescribía. A 
continuación, el sistema leía el nuevo archivo, para el cual no se había presentado contraseña. Se requería 
práctica para sincronizar bien las acciones, pero no era cosa del otro mundo. Además, si hay algo que las 
computadoras hacen bien es repetir la misma operación una y otra vez, ad nauseam. 
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Además de estos ejemplos, ha habido muchos otros problemas de seguridad y ataques en el pasado. Uno 
que ha aparecido en muchos contextos es el caballo de Troya, en el que un programa al parecer inocente 
que se distribuye ampliamente también realiza alguna función inesperada e indeseable, como robar datos y 
enviarlos por correo electrónico a un sitio distante donde posteriormente se recogen. 

Otro problema de seguridad en estos tiempos de inseguridad en el empleo es la bomba lógica, Este 
dispositivo es un fragmento de código escrito por uno de los programadores empleados actualmente por 
una compañía e insertado secretamente en el sistema operativo de producción. En tanto el programador le 
suministra su contraseña diaria, la bomba no hace nada. Sin embargo, si el programador es repentinamente 
despedido y retirado físicamente del lugar sin advertencia, no suministrará la contraseña a la bomba el día 
siguiente, y la bomba se activará. 

Tal activación podría incluir borrar el disco, borrar archivos al azar, efectuar cuidadosamente 
cambios difíciles de detectar a programas clave, o cifrar archivos indispensables. En este último caso, la 
compañía enfrenta la difícil decisión de llamar a la policía (que podría o no redundar en una condena 
judicial muchos meses después) o ceder ante el chantaje y recontratar al ex-programador como "consultor" 
por una suma astronómica para que corrija el problema (y abrigar la esperanza de que no plante más 
bombas lógicas mientras lo hace). ] 

Tal vez la violación de seguridad de computadoras más grande de todos los tiempos se inició la 
noche del 2 de noviembre de 1988 cuando un estudiante de posgrado de Comell, Robert Tappan Morris, 
liberó un programa gusano en la Internet que causó la caída de miles de máquinas en todo el mundo. 

El gusano consistía en dos programas, el autoarranque y el gusano propiamente dicho. El 
autoarranque comprendía 99 líneas escritas en C y se llamaba ll.c. Este programa se compilaba y ejecutaba 
en el sistema objetivo del ataque. Una vez que estaba funcionando, el autoarranque se conectaba a la 
máquina de la que provenía, cargaba en la máquina objetivo el gusano principal y lo ejecutaba. Después 
de tomar ciertas medidas para ocultar su existencia, el gusano examinaba la tablas de enrutamiento de su 
nuevo anfitrión para ver con qué máquinas estaba conectado éste y trataba de propagar el autoarranque a 
esas máquinas. 

Una vez establecido en una máquina, el gusano trataba de romper las contraseñas de los usuarios, 
Morris no tuvo que investigar mucho para averiguar cómo podía hacer esto. Lo único que tuvo que hacer 
fue pedir a su padre, un experto en seguridad de la National Security Agency, el organismo encargado de 
descifrar códigos en el máximo nivel de secreto del gobierno estadounidense, una reimpresión del artículo 
clásico sobre el tema que él (su padre) y Ken Thompson habían escrito diez años atrás en Bell Labs 
(Morris y Thompson, 1979). Cada contraseña rota permitía al gusano iniciar una sesión en todas las 
máquinas en las que el propietario de la contraseña tenía cuentas. 

Morris fue capturado cuando uno de sus amigos habló con el reportero de computación del New 
York Times, John Markoff, y trató de convencerlo de que el incidente había sido un accidente, de que el 
gusano era inofensivo y de que el autor se arrepentía de lo que había hecho. El día siguiente la historia 
apareció en primera plana, relegando a segundo término la elección presidencial que se iba a celebrar tres 
días después. Morris fue juzgado y condenado en una corte federal, sentenciándosele a pagar una multa de 
10 000 dólares, tres años de libertad condicional y 400 horas de servicio a la comunidad. Es probable que 
sus costos legales hayan excedido los 150 000 dólares. 
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Esta sentencia generó muchas controversias. Muchos miembros de la comunidad de la 
computación pensaban que Morris era un brillante estudiante de posgrado cuya travesura inofensiva se 
había salido fuera de control. Ningún aspecto del gusano sugirió que Morris estaba tratando de robar o 
dañar nada. Otros consideraron que se trataba de un delincuente peligroso que debía de haber ido a la 
cárcel. 

Un efecto permanente de este incidente fue el establecimiento del CERT (Equipo de Respuesta a 
Emergencias en Computadoras) que ofrece un sitio central donde se puede in formar de intentos de ingreso 
indebido, y un grupo de expertos para analizar problemas de seguridad y diseñar remedios. Si bien esta 
acción íue sin duda un paso hacia adelante, tiene su lado adverso. El CERT recaba información acerca de 
los defectos de los sistemas que pueden atacarse y cómo corregirlos. Necesariamente, el CERT circula 
ampliamente esta in formación a miles de administradores de sistemas de la Internet, lo que implica que 
"los malos" también pueden obtenerla y aprovechar los puntos débiles en las horas (o incluso días) que 
inevitablemente transcurren antes de subsanarse. 


5.4.3 Ataques genéricos contra la seguridad 


Los defectos que hemos descrito han sido corregidos, pero los sistemas operativos ordinarios siguen 
teniendo más agujeros que un cedazo. La forma usual de probar la seguridad de un sistema consiste en 
contratar un grupo de expertos, denominados equipos tigre o equipos de penetración, para ver si pueden 
violarla. Hebbard et al. (1980) intentó lo mismo con estudiantes de posgrado. A lo largo de los años, estos 
equipos de penetración han descubierto varias áreas en las que los sistemas probablemente tienen puntos 
débiles. A continuación listamos algunos de los ataques más comunes que suelen tener éxito. Al diseñar 
un sistema, asegúrese de que puede resistir ataques como éstos. 

1. Solicite páginas de memoria, espacio en disco o cintas y simplemente léalas. Muchos sistemas 
no las borran antes de asignarlas, y pueden estar llenas de información interesante escrita por su 
propietario anterior. 

2. Intente llamadas al sistema no válidas, o llamadas al sistema válidas con parámetros no válidos, 
o incluso llamadas al sistema válidas con parámetros válidos pero poco razonables. Muchos sistemas 
pueden confúndirse fácilmente. 

3. Inicie una sesión y luego oprima DEL, RUBOUT o BREAK a la mitad de la secuencia de inicio 
de sesión. En algunos sistemas, el programa de verificación de contraseñas será terminado y la sesión se 
iniciará con éxito. 

4. Trate de modificar estructuras complejas del sistema operativo mantenidas en el espacio de 
usuario (si las hay). En algunos sistemas (sobre todo en macrocomputadoras), para abrá un archivo, el 
programa construye una estructura de datos grande que contiene el nombre del archivo y muchos otros 
parámetros y la pasa al sistema. Mientras el archivo se lee y escribe, el sistema a veces actualiza la 
estructura misma. La modificación de estos campos puede dar al traste con la seguridad. 



440 


SISTEMAS DE ARCHIVOS 


CAPA 


5. Burle al usuario escribiendo un programa que escriba "login:" en la pantalla y luego 
desaparezca. Muchos usuarios se sentarán frente a la terminal y proporcionarán sin reparo su nombre de 
inicio de sesión y su contraseña, que el programa registrará cuidadosamente para su malvado amo. 

6. Busque manuales que adiestren a "No hacer X". Intente tantas variaciones de X como le sean 
posibles. 

7. Convenza a un programador del sistema que modifique éste de modo que pase por alto ciertas 
verificaciones de seguridad cruciales para cualquier usuario que proporcione su nombre de inicio de 
sesión. Este ataque se conoce como trampa (trapdoor). 

8. Si falla todo lo demás, el invasor podría buscar al secretario del director del centro de cómputo 
y ofrecerle un soborno sustancial. Es probable que el secretario tenga acceso a todo tipo de información 
útil, y generalmente recibe un salario bajo. No subestime los problemas causados por el personal. 

Éstos y otros ataques se analizan en Linde (1975). 


Virus 


Una categoría de ataque especial es el virus de computadora, que se ha convertido en un problema 
importante para muchos usuarios. Un virus es un fragmento de programa que se anexa a un programa 
legítimo con la intención de in fectar otros programas. La única diferencia respecto a un gusano es que el 
virus "se monta" en un programa existente, en tanto que el gusano es un programa completo por sí solo. 
Tanto los virus como los gusanos intentan propagarse y pueden causar daños graves. 

Un virus representativo funciona como sigue. La persona que escribe el virus primero produce un 
programa nuevo útil, que a menudo es un juego para MS-DOS. Este programa contiene código del virus 
oculto en su interior. A continuación el juego se carga en un sistema de tablero de boletines público o se 
ofrece gratuitamente o por un precio módico en un disquete. Luego se hace publicidad al programa, y la 
gente comienza a descargarlo y usarlo. La construcción de un virus no es sencilla, así que las personas que 
lo llevan a cabo siempre son brillantes, y la calidad del juego u otro programa a menudo es excelente. 

Cuando se pone en marcha el programa, de inmediato comienza a examinar todos los programas 
binarios del disco duro para ver si ya están infectados. Cuando se encuentra un programa no infectado, 
éste queda infectado anexando el código del virus al final del archivo, y sustituyendo la primera 
instrucción por un salto al virus. Cuando el código del virus termina de ejecutarse ejecuta la instrucción 
que antes era la primera y luego salta a la segunda instrucción. De esta forma, cada vez que se ejecute un 
programa infectado, tratará de infectar más programas. 

Además de infectar otros programas, el virus puede hacer otras cosas, como borrar, modificar o 
cifrar archivos. Un virus llegó a exhibir un mensaje de extorsión en la pantalla, exigiendo al usuario enviar 
500 dólares en efectivo a un apartado postal en Panamá o resignarse a la pérdida permanente de sus datos 
y a daños al hardware. 



SEC.5.4 


SEGURIDAD 


441 


También es posible que un virus infecte el sector de arranque del disco duro, haciendo imposible 
arrancar la computadora. Un virus así podría pedir una contraseña, que el escritor del virus podría ofrecer 
a cambio de unos cuantos billetes de baja denominación sin marcas. 

Los problemas de virus son más fáciles de prevenir que de curar. El proceder más seguro consiste 
en comprar sólo software debidamente empacado en establecimientos respetables. Cargar software 
gratuito de los tableros de boletines u obtener copias pirata en disquetes es buscar problemas. Existen 
paquetes comerciales antivirus, pero algunos de ellos sólo buscan virus conocidos específicos. 

Una estrategia más general consiste en formatear totalmente el disco duro, incluido el sector de 
arranque. A continuación, se instala todo el software confiable y se calcula una suma de verificación para 
cada archivo. No importa qué algoritmo se use, en tanto tenga suficientes bits (al menos 32). Luego debe 
almacenarse la lista de pares (archivo, suma de verificación) en un lugar seguro, ya sea fuera de línea en 
un disco flexible o en línea, pero cifrado. A partir de ese momento, cada vez que el sistema se arranque, se 
deberán recalcular todas las sumas de verificación y compararse con la lista segura de sumas originales. 
Cualquier archivo cuya suma actual difiera de la original puede estar infectado. Si bien esta estrategia no 
impide la infección, al menos permite detectarla en una etapa temprana. 

Puede hacerse más difícil la infección si se impide que los usuarios ordinarios escriban en el 
directorio donde residen los programas binarios. Esta técnica obstaculiza la infección de otros archivos 
binarios por parte del virus. Aunque esto es factible en UNIX, no puede aplicarse a MS- DOS porque en 
este sistema no es posible restringir la escritura de directorios. 


5.4.4 Principios de diseño para la seguridad 


Los virus ocurren en su mayor parte en los sistemas de escritorio. En los sistemas más grandes se 
presentan otros problemas y se requieren otros métodos para enfrentarlos. Saitzer y Schroeder (1975) han 
identificado mvarios principios generales que pueden servir como guía para diseñar sistemas seguros. A 
continuación resumiremos sus ideas, que se basaron en la experiencia con MULTICS. 

Primero, el diseño del sistema debe ser público. Suponer que el intruso no sabe cómo funciona el 
sistema sólo hace que los diseñadores se engañen a sí mismos. 

Segundo, la política por omisión debe ser no otorgar acceso. Los errores en los que se rehúsa un 
acceso legítimo se informarán con mucha mayor rapidez que los errores en los que se permite un acceso 
no autorizado. 

Tercero, se debe verificar la vigencia de la autorización. El sistema no debe comprobar si se tiene 
permiso, determinar que el acceso está permitido y luego guardar esta información para uso subsecuente. 
Muchos sistemas verifican el permiso cuando se abre un archivo, pero no después. Esto implica que un 
usuario que abre un archivo y lo mantiene unido durante semanas seguirá teniendo acceso, incluso si el 
propietario ha modificado ya la protección del archivo. 

Cuarto, debe darse a cada proceso el mínimo privilegio posible. Si un editor sólo tiene 
autorización para acceder al archivo que se va a modificar (y que se especifica cuando se invoca el 
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editor), los editores con caballos de Troya no podrán causar mucho daño. Este principio implica un 
esquema de protección de grano fino. Trataremos tales equemas más adelante en este capítulo. 

Quinto, el mecanismo de protección debe ser sencillo, uniforme, y estar incorporado en las capas 
más bajas del sistema. Tratar de añadir seguridad a un sistema inseguro existente es casi imposible; la 
seguridad, al igual que la exactitud, no es una característica que se pueda agregar. 

Sexto, el esquema escogido debe ser psicológicamente aceptable. Si los usuarios piensan que 
proteger sus archivos implica demasiado trabajo, simplemente no lo harán. Sin embargo, se quejarán a voz 
en cuello si algo sale mal. Las respuestas del tipo "usted fue el culpable" no suelen ser bien recibidas. 


5.4.5 Verificación de autenticidad de usuarios 


Muchos esquemas de protección se basan en el supuesto de que el sistema conoce la identidad de cada 
usuario. El problema de identificar los usuarios cuando inician una sesión se denomina verificación de 
autenticidad de usuarios. La mayor parte de los métodos de verificación de autenticidad se basan en 
identificar algo que el usuario conoce, tiene o es. 


Contraseñas 


La forma de verificación de autenticidad más ampliamente utilizada es pedir al usuario que teclee una 
contraseña. La protección mediante contraseña es fácil de entender y de implementar. En UNIX el 
esquema funciona como sigue. El programa de inicio de sesión pide al usuario que teclee su nombre y 
contraseña. De inmediato, la contraseña se cifra. Luego, el programa de inicio de sesión lee el archivo de 
contraseñas, que es una serie de líneas ASCII, una por usuario, hasta encontrar la que contiene el nombre 
de inicio de sesión del usuario. Si la contraseña (cifrada) contenida en esta línea concuerda con la 
contraseña cifrada que se acaba de calcular, se permite el inicio de la sesión; de lo contrario, se rechaza. 

La verificación de autenticidad de las contraseñas es fácil de vencer. Es frecuente leer acerca de 
grupos de estudiantes de preparatoria, o incluso de secundaria, que, con la ayuda de sus computadoras 
caseras, se introducen en algún sistema de secreto máximo, propiedad de una corporación gigantesca o 
una dependencia del gobierno. Prácticamente en todos los casos la intrusión se efectúa adivinando una 
combinación de nombre de usuario y contraseña. 

Aunque se han efectuado estudios más recientes (p. ej., Klein, 1990), el trabajo clásico sobre 
seguridad de contraseñas sigue siendo el realizado por Morris y Thompson (1979) sobre sistemas UNIX. 
Ellos compilaron una lista de probables contraseñas: nombres de pila y apellidos, nombre» de calle o de 
ciudad, palabras de un diccionario de tamaño moderado (también palabras escritas al revés), números de 
placas de automóvil, y cadenas cortas de caracteres aleatorios. 

A continuación, ellos cifraron todas estas claves empleando el algoritmo de cifrado de contraseñas 
conocido y verificaron si alguna de las contraseñas cifradas coincidía con una entrada de su lista. Más del 
86% de todas las contraseñas resultaron estar en su lista. 

Si todas las contraseñas consistieran en siete caracteres escogidos al azar de entre los 95 caracteres 
ASCII imprimibles, el espacio de búsqueda es de 957, o sea, cerca de 7x1013.A razón 
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de 1000 cifrados por segundo, se requerirían 2000 años para construir la lista contra la cual se cotejaría el 
archivo de contraseñas. Además, la lista llenaría 20 millones de cintas magnéticas. Aun el requisito de que 
las contraseñas contengan por lo menos una letra minúscula, una mayúscula y un carácter especial y 
tengan por lo menos siete u ocho caracteres de longitud representaría una mejora considerable respecto a 
dejar que los usuarios escojan a su antojo una contraseña. 

Incluso si se considera políticamente imposible exigir que los usuarios escojan contraseñas 
razonables, Morris y Thompson han descrito una técnica que hace que su propio ataque (cifrar una gran 
cantidad de contraseñas por adelantado) sea casi inútil. Su idea es asociar un número aleatorio de n bits a 
cada contraseña. El número aleatorio se cambia cada vez que se cambia la contraseña, y se almacena en el 
archivo de contraseñas sin cifrarse, de modo que todo mundo pueda leerlo. En vez de almacenar la 
contraseña cifrada en el archivo de contraseñas, la contraseña y el número aleatorio primero se concatenan 
y luego se cifran juntos. Este resultado cifrado se almacena en el archivo de contraseñas. 

Consideremos ahora las implicaciones para un intruso que desea construir una lista de contraseñas 
probables, cifrarlas, y guardar el resultado en un archivo ordenado, /, con objeto de poder buscar las 
contraseñas cifradas rápidamente. Si un intruso sospecha que Marilyn podría ser una contraseña, no basta 
ya con cifrar Marilyn y colocar el resultado en/; es necesario cifrar 2 n cadenas, como MarilynOOOO, 
MarilynOOOl, Marilyn.0002, etc., y colocarlas todas en/. Esta técnica aumenta el tamaño de/en 2". UNIX 
utiliza este método con n = 12. El método se conoce como la acción de saltar el archivo de contraseñas. 
Algunas versiones de UNIX hacen que el archivo de contraseñas mismo no pueda leerse, y proporcionan 
un programa que consulta entradas cuando se le solicita, incorporando un pequeño retardo suficiente para 
reducir drásticamente la rapidez con que puede actuar cualquier atacante. 

Si bien este método ofrece protección contra intrusos que tratan de precalcular una lista larga de 
contraseñas cifradas, no hace mucho para proteger a un usuario llamado David cuya contraseña también 
sea David. Una forma de fomentar la selección de mejores contraseñas por parte de los usuarios es hacer 
que la computadora los asesore. Algunas computadoras tienen un programa que genera palabras aleatorias 
sin significado pero fáciles de pronunciar, como mamuseo, raflije o trupimpa que se pueden usar como 
contraseña (de preferencia incorporando mayúsculas y wacteres especiales). 

Otras computadoras obligan a los usuarios a cambiar sus contraseñas con regularidad, a fin e 
limitar los daños en caso de una fúga de contraseñas. La forma más extrema de este enfoque es la 
contraseña de una sola vez. Cuando se usa este tipo de contraseñas, el usuario recibe un libro que contiene 
una lista de contraseñas. En cada inicio de sesión se usa la siguiente contraseña de lá lista. Si un intruso 
llega a descubrir una contraseña, de nada le servirá, ya que en la siguiente ocasión debe usarse una 
contraseña distinta. Se sugiere al usuario tratar de no perder el libro de contraseñas. 

Huelga decir que, mientras se está tecleando una contraseña, la computadora no debe exhibir los 
caracteres tecleados, a fin de protegerlos de ojos curiosos en las cercanías de la terminal. Lo que es menos 
obvio es que las contraseñas nunca deben almacenarse en la computadora en forma no cifrada. Además, ni 
siquiera los administradores del centro de cómputo deben poseer copias no cifradas. Mantener contraseñas 
no cifradas en cualquier sitio es buscarse problemas. 
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Una variación del concepto de contraseña es hacer que cada usuario nuevo proporcione una larga 
lista de preguntas y respuestas que después se guardan en la computadora en forma cifrada. Las preguntas 
deben ser de tal naturaleza que el usuario no necesite anotarlas. Por ejemplo, 

1. ¿Quién es el hermano de Marines? 

2. ¿En qué calle estaba mi escuela primaria? 

3. ¿Qué clase impartía la Sra. Fajardo? 

Al iniciarse la sesión, la computadora hace una de estas preguntas al azar y verifica la respuesta. 

Otra variación es la de reto-respuesta. Cuando se emplea este enfoque, la persona escoge un 
algoritmo al inscribirse como usuario, digamos x2. Cuando se inicia una sesión, la computadora teclea un 
argumento, digamos 7, en cuyo caso el usuario teclea 49. El algoritmo puede ser diferente en la mañana y 
en la tarde, en diferentes días de la semana, desde diferentes terminales, etcétera. 


Identificación física 


Un enfoque de autorización totalmente distinto es verificar si el usuario tiene algún objeto, normalmente 
una taijeta de plástico con una tira magnética. La taijeta se inserta en la terminal, la cual entonces 
determina quién es el dueño. Este método se puede combinar con una contraseña, de modo que el usuario 
sólo pueda iniciar una sesión si (1) tiene la tarjeta y (2) conoce la contraseña. Las máquinas de entrega de 
efectivo automáticas suelen funcionar de esta manera. 

Otra estrategia consiste en medir características físicas que sean difíciles de falsificar. Por 
ejemplo, un lector de huellas digitales o de patrón de voz en la terminal podría verificar la identidad del 
usuario. (La búsqueda se agiliza si el usuario le dice a la computadora quién es, en lugar de hacer que la 
computadora compare la huella digital con toda la base de datos.) El reconocimiento visual directo todavía 
no es factible pero algún día podría serlo. 

Otra técnica es el análisis de firmas. El usuario firma su nombre con una pluma especial conectada 
a la terminal, y la computadora la compara con un espécimen conocido almacenado en línea. Mejor aún es 
no comparar la firma, sino comparar los movimientos de la pluma mi entras se firma. Un buen falsificador 
podría ser capaz de copiar la firma, pero no sabrá en qué orden se efectuaron exactamente los trazos. 

El análisis de la longitud de los dedos resulta sorprendentemente práctico. Cuando se emplea esto, 
cada terminal tiene un dispositivo como el de la Fig. 5-21. El usuario inserta su mano en él, y se mide la 
longitud de todos sus dedos y se coteja con la base de datos. 

Podríamos seguir con más y más ejemplos, pero bastarán otros dos para dejar asentado un punto 
importante. Los gatos y otros animales marcan su territorio orinando a lo largo de superímetro. Al parecer, 
los gatos pueden identificarse unos a otros de esta manera. Supónganla) que alguien inventa un dispositivo 
pequeño capaz de efectuar un análisis de orina instantáneo, con lo cual se lograría una identificación 
infalsificabie. Cada terminal podría equiparse con uno de estos dispositivos, junto con un letrero discreto 
que dijera "Para iniciar una sesión, sírvase depo- 
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Figura 5-21. Dispositivo para medir la longitud de los dedos. 


sitar una muestra aquí". Éste podría ser un sistema inviolable, pero probablemente enfrentaría un problema 
grave de falta de aceptación por parte de los usuarios. 

Lo mismo podría decirse de un sistema consistente en una chinche o chincheta y un pequeño 
espectrógrafo. Se pediría al usuario que oprimiera su pulgar contra la chincheta, extrayendo así una gota 
de sangre para análisis espectrográfico. Lo que tratamos de decir es que cualquier esquema de verificación 
de autenticidad debe ser psicológicamente aceptable para la comunidad de usuarios. Las mediciones de 
longitud de los dedos probablemente no causarán problemas, pero incluso algo tan poco intrusivo como 
almacenar huellas digitales en línea podría ser inaceptable para muchas personas. 


Medidas preventivas 


Las instalaciones de computadoras que toman realmente en serio la seguridad, cosa que con freuencia 
sucede al día siguiente de que un intruso se metiera en el sistema, causando daños importantes, suelen 
adoptar medidas para dificultar mucho más el ingreso no autorizado. Por ejemplo podría permitirse a cada 
usuario iniciar una sesión sólo desde una terminal específica, y solo durante ciertos días de la semana y 
ciertas horas del día. 

Podría hacerse que las líneas telefónicas de marcado para ingreso funcionen como sigue, 
cualquiera puede marcar e iniciar una sesión, pero de inmediato el sistema rompe la conexión y llama al 
usuario a un número convenido con anterioridad. Esta medida implica que un intruso no puede 
simplemente tratar de introducirse en el sistema desde cualquier línea telefónica; sólo se 
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puede usar la línea telefónica (de la casa) del usuario. En cualquier caso, sea que llame de vuelta al usuario 
o no, el sistema debe tardar por lo menos 10 segundos en verificar cualquier contraseña que se introduzca 
por una línea de marcado, y deberá alargar este lapso después de varios intento fallidos de iniciar la 
sesión, a fin de reducir la rapidez con que los intrusos pueden efectuar sus intentos. Después de tres 
intentos de iniciar la sesión sin éxito, la línea deberá desconectarse durante 10 mi nutos y notificarse al 
personal de seguridad. 

Todos los inicios de sesión deben registrarse. Cuando un usuario inicia una sesión, el sistema debe 
informar el tiempo y la terminal del inicio previo, con objeto de que él pueda détectar posibles intrusiones. 

El siguiente nivel hacia arriba es poner trampas con camada para atrapar intrusos. Un esquema 
sencillo es tener un nombre de inicio de sesión especial con una contraseña fácil (p. Ej., nombre de 
entrada: guest, contraseña: guest). Siempre que alguien inicia una sesión empleando este nombre, se 
notifica de inmediato a los especialistas de seguridad del sistema. Otras trampas pueden ser errores fáciles 
de encontrar en el sistema operativo y cosas similares, diseñadas para atrapar a los intrusos con las manos 
en la masa. Stoll (1989) ha escrito un relato entretenido acerca de las trampas que puso para rastrear un 
espía que se introdujo en una computadora universitaria en busca de secretos militares. 


5.5 MECANISMOS DE PROTECCIÓN 


En las secciones anteriores hemos examinado muchos problemas potenciales, algunos técnicos otros no. 
En las siguientes secciones nos concentraremos en algunos de los métodos técnicos detallados que se 
emplean en los sistemas operativos para proteger los archivos y otras cosas. Todas estas técnicas 
establecen una distinción clara entre política (contra quién se van a proteger los datos de quién) y 
mecanismo (cómo hace el sistema que se cumpla la política). La separaciónde política y mecanismo se 
trata en (Levin et al., 1975). Nosotros haremos hincapié en el mecanismo, no en la política. Si se desea 
consultar material más avanzado, véase (Sandhu, 1993). 

En algunos sistemas, la protección se impone mediante un programa llamado monitor de 
referencias. Cada vez que se intenta un acceso a un recurso que pudiera estar protegido, el sistema pide 
primero al monitor de referencias que verifique que tal acceso está permitido. El monitor examina 
entonces sus tablas de política y toma una decisión. A continuación describiremos el entorno en el que 
opera el monitor de referencias. 


5.5.1 Dominios de protección 


Un sistema de computadora contiene muchos "objetos" que deben protegerse. Estos objeto pueden ser 
hardware (p. ej., CPU, segmentos de memoria, unidades de disco o impresora) software (p. ej., procesos, 
archivos, bases de datos o semáforos). 

Cada objeto tiene un nombre único con el cual se hace referencia a él, y un conjunto finita de 
operaciones que los procesos pueden efectuar con él. READ y WRITE son operaciones apropiada para un 
archivo; UP y DOWN tienen sentido con un semáforo. 
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Es evidente que se requiere un mecanismo para prohibir a los procesos que accedan a objetos que no están 
autorizados para usar. Además, este mecanismo debe permitir restringir los procesos a un subconjunto de 
las operaciones permitidas cuando sea necesario. Por ejemplo, el proceso A podría tener derecho a leer, 
pero no escribir, el archivo F. 

A fin de analizar los diferentes mecanismos de protección, resulta útil introducir el concepto de 
dominio. Un dominio es un conjunto de pares (objeto, derechos). Cada par especifica un objeto y algún 
subconjunto de las operaciones que se pueden efectuar con él. Un derecho en este contexto se refiere al 
permiso para efectuar una de las operaciones. 

En la Fig. 5-22 se pueden ver tres dominios, y se muestran los objetos de cada dominio así como los derechos [leer 
(R), escribir (W), ejecutar (X)] disponibles para cada objeto. Obsérvese que Impresoral está en dos dominios al 
mismo tiempo. Aunque no se muestra en este ejemplo, es posible que el mismo objeto esté en múltiples dominios 
con diferentes derechos en cada uno. 



Figura 5-22. Tres dominios de protección 


, En cada instante, cada proceso se ejecuta en algún dominio de protección. En otras palabras, existe una 
colección de objetos a los que puede acceder, y para cada objeto tiene ciertos derechos. Los procesos 
pueden cambiar de un dominio a otro durante su ejecución. Las reglas para la conmutación de dominio 
dependen mucho del sistema del que se trate. 

A fin de hacer más concreta la idea de dominio de protección, examinemos UNIX. En UNIX, el 
dominio de un proceso está definido por su uid y su gid. Dada una combinación (uid, gid), es posibie 
preparar una lista completa de todos los objetos (archivos, incluidos los dispositivos de Ey S presentados 
por archivos especiales, etc.), a los que se puede acceder, y si se puede acceder a ellos para leer, escribir o 
ejecutar. Dos procesos con la misma combinación (uid, gid) tienen acceso a exactamente el mismo 
conjunto de objetos. Dos procesos con diferentes valores (uid, gid) | tienen acceso a diferentes conjuntos 
de archivos, aunque en la mayor parte de los casos eltraslapo es considerable. 

Además, cada proceso en UNIX tiene dos mitades: la parte del usuario y la parte del kemel. 
Cuando ceso emite una llamada al sistema, conmuta de la parte del usuario a la parte del kemel. Esta 
ultima tiene acceso a un conjunto de objetos distinto del de la parte del usuario. Por ejemplo, el kemel 
puede acceder a todas las páginas de la memoria física, a todo el disco y a todos los demás recursos 
protegidos. Por tanto, una llamada al sistema causa una conmutación de do mi nio. 

Cuando un proceso efectúa EXEC con un archivo que tiene el bit SETUID o SETGID encendido 
adquiere un nuevo uid o gid efectivo. Al tener una combinación (uid, gid) diferente, el proceso tiene a su 
disposición un conjunto distinto de archivos y operaciones. La ejecución de un programa con SETUID o 
SETGID también es una conmutación de dominio, ya que cambian los derechos que se tienen. 
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Una pregunta importante es, ¿cómo hace el sistema para saber cuál objeto pertenece a cuál 
dominio? Conceptualmente, al menos, podemos imaginar una matriz grande cuyas filas son los dominios 
y cuyas colu mn as son los objetos. Cada cuadro indica los derechos, en su caso, que el dominio contiene 
para el objeto. En la Fig. 5-23 se muestra la matriz para la Fig. 5-22. Dada esta matriz y el número de 
dominio actual, el sistema puede saber si se permite cierto tipo de acceso a un objeto dado desde el 
dominio especificado. 



Archivo 1 

Archivo2 

Archrvo3 

Objeto 

Archrvo4 A/chivoí 

Archivo® 

Impresora) Grafrcaaor2 

Dominio 

1 

Leer 

Leer 

Escribir 







2 



Leer 

Leer 

Escribir 

Ejecutar 

Leer 

Escribir 


Escribir 


3 






Leer 

Escribir 

Ejecutar 

Escnbir 

Escrtor 


Figura 5-23. Una matriz de protección. 


La conmutación de dominio misma se puede incluir fácilmente en el modelo de matriz si nos 
damos cuenta de que un dominio es también un objeto, con la operación ENTER (entrar). La Fig. 5-24 
muestra otra vez la matriz de la Fig. 5-23, sólo que ahora incluye los tres dominios mismos como objetos. 
Los procesos del dominio 1 pueden conmutar al dominio 2 pero, una vez ahí, ya no pueden regresar. Esta 
situación modela la ejecución de un programa SETUID en UNIX. No se permiten otras conmutaciones de 



Figura 5-24. Matriz de protección con dominios como objetos. 


5.5.2 Listas de control de acceso 


En la práctica casi nunca se almacena una matriz como la de la Fig. 5-24 porque es grande y no muy 
poblada. La mayor parte de los dominios no tienen acceso a la mayor parte de los objetos, asi que 
almacenar una matriz muy grande en su mayor parte vacía es un desperdicio de espacio en disco. Dos 
métodos que sí son prácticos son almacenar la matriz por filas o por columnas, y 
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luego almacenar sólo los elementos no vacíos. Los dos enfoques son sorprendentemente distintos. En esta 
sección examinaremos el almacenamiento por columna; en la siguiente veremos el almacenamiento por 
fila. 


La primera técnica consiste en asociar a cada objeto una lista (ordenada) que contiene todos los 
dominios que pueden acceder al objeto, y cómo pueden hacerlo. Esta lista se denomina lista de control de 
acceso, o ACL. Si esto se implementara en UNIX, la forma más fácil sería colocar la ACL para cada 
archivo en un bloque de disco aparte e incluir el número de bloque en el nodo-i del archivo. Ya que sólo 
se almacenan las entradas no vacías de la matriz, el almacenamiento total requerido para todas las ACL 
combinadas es mucho menor que el que se necesitaría para toda la matriz. 

Como ejemplo del funcionamiento de las ACL, sigamos imaginando que se usaran en UNIX, 
donde un dominio se especifica con un par (uid, gid). De hecho, las ACL se usaron en el precursor de 
UNIX, MULTICS, más o menos de la forma que vamos a describir, así que el ejemplo no es tan 
hipotético. 

Supongamos ahora que tenemos cuatro usuarios (o sea, uids) Juan, Eva, Rita y Maite, que 
pertenecen a los grupos sistema, personal, estudiante y estudiante, respectivamente. Supongamos también 
que ciertos archivos tienen las siguientes ACL: 


ArchivoO: (Juan, *, RWX) 

Archivo 1: (Juan, sistema, RWX) 

Archivo!: (Juan, *, RW-), (Eva, personal, RW-), (Maite, *, RW-) 
Archivo3: (*, estudiante, R—) 

Archivo4: (Rita, *, —), (*, estudiante, R—) 


Cada entrada de ACL, entre paréntesis, especifica un uid, un gid y los accesos permitidos (R = leer, W = 
escribir, X — ejecutar). Un asterisco indica todos los uids o gids. ArchivoO puede ser leído, escrito o 
ejecutado por cualquier proceso cuyo uid sea Juan, sea cual sea su gid. Sólo pueden acceder a Archivol los 
procesos con uid = Juan y gid = sistema. Un proceso que tiene uid = Juan y gid = personal puede acceder a 
ArchivoO pero no a Archivol. Archivo! puede ser leído o escrito por procesos con uid = Juan y cualquier 
gid, ser leído por procesos con uid = Eva y gid • = personal, o por procesos con uid = Maite y cualquier 
gid. Archivo3 puede ser leído por cualquier estudiante. Archivo4 resulta especialmente interesante. Su 
ACL dice que cualquiera con uid IB .Rito, en cualquier grupo, no tiene ningún acceso, pero que todos los 
demás estudiantes pueden leerlo. Mediante las ACL es posible prohibir a uids o gids específicos el acceso 
a un objeto, pemitiéndolo a todos los demás de la misma clase. 

Hasta aquí lo que UNIX no hace. Veamos ahora lo que .«hace. UNIX proporciona tres bits, rwx, 
por archivo para el propietario, el grupo del propietario y otros. Este esquema es parecido a la ACL, pero 
comprimido a nueve bits. Se trata de una lista asociada con el objeto que indica quién puede acceder a él y 
cómo. Si bien el esquema UNIX de nueve bits es obviamente menos general que un sistema ACL con 
todas las de la ley, en la práctica es adecuado, y su implementación es mucho más sencilla y económica. 

El propietario de un objeto puede cambiar su ACL en cualquier instante, así que es fácil prohibir 
accesos que antes se permitían. El único problema es que el cambio a la ACL probable- 
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mente no afectará a los usuarios que actualmente estén utilizando el objeto (p. ej., que tengan abierto el 
archivo). 


5.5.3 Capacidades 


La otra forma de "rebanar" la matriz de la Fig. 5-24 es por filas. Cuando se emplea este método, cada 
proceso tiene asociada una lista de los objetos a los que puede acceder, junto con una indicación de cuáles 
operaciones puede efectuar con cada uno; en otras palabras, su dominio. Esta lista se denomina lista de 
capacidades, y los elementos individuales que contiene se llaman capacidades (Dermis y Van Hom, 1966; 
Fabry, 1974). 

En la Fig. 5-25 se muestra una lista de capacidades típica. Cada capacidad tiene un campo Tipo, 
que indica la clase de objeto de que se trata, un campo Derechos, que es un mapa de bits que indica cuáles 
de las operaciones que pueden efectuarse con este tipo de objeto están permitidas, y un campo Objeto, que 
es un apuntador al objeto mismo (p. ej., su número de nodo-i). Las listas de capacidades son ellas mismas 
objetos y se puede apuntar a ellas desde otras listas de capacidades, facilitando así el compartimiento de 
subdominios. Es común hacer referencia a las capacidades por su posición en la lista. Un proceso podría 
decir: "leer 1K del archivo al que apuntala capacidad 2". Esta forma de direccionamiento es similar al 


empleo de descriptores de archivo en UNIX. 



# 

Tipo Derechos 

Objeto 


0 

Archivo 

R— 

Apuntador a Archivos 


1 

Archivo 

RWX 

Apuntador a Archivo4 


2 

Archivo 

RW- 

Apuntador a Archivos 


3 

Apuntador 

-W- 

Apuntador a Impresora"! 


Figura 5-25. La lista de capacidades para el dominio 2 de la Pig. 5-23. 


Es obvio que las listas de capacidad, o listas C, como también se les llama, deben estar protegidas 
contra alteración por parte del usuario. Se han propuesto tres métodos para protegerlas. El primero 
requiere una arquitectura etiquetada, un diseño de hardware en el que cada palabra de la memoria tiene un 
bit extra (o etiqueta) que indica si la palabra contiene una capacidad o no. El bit de etiqueta no se utiliza 
en las instrucciones ordinarias de aritmética, comparación u otro tipo, y sólo puede ser modificado por 
programas que se ejecuten en modo de kemel (es decir, el sistema operativo). 

El segundo método consiste en mantener la lista C dentro del sistema operativo y hacer que los 
procesos hagan referencia a las capacidades sólo por su número de ranura, como se mencionó antes. 
Hydra (Wulf et al., 1974) funcionaba de esta forma. 

El tercer método es mantener la lista C en el espacio de usuario, pero cifrar cada capacidad con 
una clave secreta que el usuario desconoce. Este enfoque es muy apropiado para sistemas distribuidos, y 
es utilizado ampliamente porAmoeba (Tanenbaum et al., 1990). 
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Además de los derechos específicos que dependen del objeto, como leer y ejecutar, las 
capacidades suelen tener derechos genéricos que son aplicables a todos los objetos. Como ejemplos de 
derechos genéricos podemos citar: 

1. Copiar capacidad: crear una nueva capacidad para el mismo objeto. 

2. Copiar objeto: crear un objeto duplicado con una nueva capacidad. 

3. Quitar capacidad: eliminar una entrada de la lista C sin afectar el objeto. 

4. Destruir objeto: eliminar permanentemente un objeto y una capacidad. 


Un último comentario que vale la pena hacer acerca de los sistemas de capacidades es que es muy 
difícil revocar el acceso a un objeto. No es fácil para el sistema encontrar todas las capacidades vigentes 
para cualquier objeto y revocarlas, ya que pueden estar almacenadas en listas C por todo el disco. Una 
estrategia es hacer que cada capacidad apunte a un objeto indirecto, no al objeto mismo. Si el sistema hace 
que el objeto indirecto apunte al objeto real, siempre podrá romper esa conexión, invalidando así las 
capacidades. (Más tarde, cuando se presente al sistema una capacidad para el objeto indirecto, el usuario 
descubrirá que el objeto indirecto ahora apunta a un objeto nulo.) 

Otra forma de lograr la revocación es el esquema empleado en Amoeba. Cada objeto contiene un 
número aleatorio largo, que también está presente en la capacidad. Cuando se presenta una | capacidad 
para usarse, se comparan ambos números, y sólo se permite la operación si los números coinciden. El 
propietario de un objeto puede solicitar que se cambie el número aleatorio del objeto, cancelando así la 
validez de las capacidades existentes. Ninguno de estos esquemas permite la revocación selectiva, es 
decir, revocar el permiso de José, pero de nadie más. 


P.5.4 Canales encubiertos 


Aun con listas de control de acceso y capacidades, puede haber puntos débiles en la seguridad. En (sta 
sección estudiaremos una clase de problema. Las ideas aquí expuestas se deben a Lampson (1973). 

El modelo de Lampson implica tres procesos y aplica primordialmente a sistemas de tiempo 
impartido grandes. El primer proceso es el cliente, que desea que el segundo proceso, el serví», efectúe 
cierto trabajo. El cliente y el servidor no se tienen confianza ciega. Por ejemplo, la legación del servidor es 
ayudar a los clientes a llenar sus formas fiscales. Los clientes temen Sel servidor registre en secreto sus 
datos financieros, por ejemplo, manteniendo una lista de ién gana cuánto, y que luego venda la lista. El 
servidor teme que los clientes tratarán de robar el lioso programa fiscal. 

El tercer proceso es el colaborador, que está conspirando con el servidor para robar en efecto los 
confidenciales del cliente. El colaborador y el servidor por lo regular son propiedad de la misma persona. 
Los tres procesos se muestran en la Fig. 5-26. El objeto de este ejercicio es diseñar un sistema en el que 
sea imposible que el servidor filtre al colaborador la información que recibió legítimamente del cliente. 
Lampson llamó a éste el problema de confin ami ento. 
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Figura 5-26. (a) Los procesos cliente, servidor y colaborador, (b) El servidor encapsulado 
aún puede filtrar información al colaborador a través de canales encubiertos. 


Desde el punto de vista del diseñador del sistema, el objetivo es encapsular o confinar el servidor de tal 
manera que no pueda pasar información al colaborador. Si usamos un esquema de matriz de protección 
fácilmente podremos garantizar que el servidor no podrá comunicarse con el colaborador escribiendo un 
archivo al que el colaborador tenga acceso de lectura. Probablemente también podremos asegurar que el 
servidor no podrá comunicarse con el colaborador empleando el mecanismo de comunicación entre 
procesos del sistema. 

Por desgracia, puede haber canales de comunicación más sutiles. Por ejemplo, el servidor puede 
tratar de comunicar una comente de bits binaria como sigue. Para enviar un bit, el servidor calcula a 
máxima velocidad durante un intervalo de tiempo fijo. Para enviar un bit O, el servidor se duerme durante 
un lapso idéntico. 

El colaborador puede tratar de detectar la corriente de bits vigilando cuidadosamente su tiempo de 
respuesta. En general, se obtendrá una mejor respuesta cuando el servidor está enviando un 0 que cuando 
está enviando un 1. Este canal de comunicación se denomina canal encubierto y se ilustra en la Fig. 5- 
26(b). 

Desde luego, el canal encubierto es ruidoso, pues contiene mucha información ajena, pero es 
posible tran s mitir información de forma confiable a través de un canal ruidoso empleando un código de 
corrección de errores (p. ej., un código de Hamming, o incluso algo más complejo). El empleo de un 
código de corrección de errores reduce aún más el ancho de banda, ya de por si pequeño, del canal 
encubierto, pero podría ser suficiente para filtrar una cantidad sustancial de información. Es evidente que 
ningún modelo de protección basado en una matriz de objetos y dominios va a prevenir este tipo de fugas. 

La modulación de la utilización de la CPU no es el único canal encubierto. La tasa de paginación 
también puede modularse (muchas fallas de página para un 1, ninguna falla para un 0). De hecho, casi 
cualquier forma de degradar el rendimiento del sistema de forma sincronizada es un candidato. Si el 
sistema cuenta con un mecanismo de candados para los archivos, el servidor puede poner un candado a un 
archivo para indicar un 1, y quitar el candado para indicar un 0. En algunos sistemas, un proceso puede 
detectar la situación de un candado incluso en un archivo al que no puede acceder. 
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La adquisición y liberación de recursos dedicados (unidades de cinta, graficadores, etc.), también 
puede aprovecharse para enviar señales. El servidor adquiere el recurso para enviar un 1 y lo libera para 
enviar un 0. En ÜNIX, el servidor podría crear un archivo para indicar un 1 y eli mi narlo para indicar un 0; 
el colaborador podría usar la llamada al sistema ACCESS para ver si existe el archivo. Esta llamada 
funciona incluso si el colaborador no tiene permiso para usar el archivo. Por desgracia, existen muchos 
otros canales encubiertos. 

Lampson también menciona una forma de filtrar información al propietario (humano) del proceso 
servidor. Es de suponer que dicho proceso podrá informar a su dueño de cuánto trabajo efectuó para el 
cliente, a fin de poder cobrarle la cantidad correspondiente. Si el cargo por el servicio es de, digamos, 100 
dólares y los ingresos del cliente ascienden a 53K dólares, el servidor podría informar el cargo como 
100.53 dólares a su propietario. 

Tan sólo encontrar todos los canales encubiertos, no digamos bloquearlos, es extremadamente 
difícil. En la práctica no hay mucho que se pueda hacer. La introducción de un proceso que cause fallas de 
página al azar, o dedique su tiempo a degradar el rendimiento del sistema de otras formas a fin de reducir 
el ancho de banda de los canales encubiertos no es una propuesta atractiva. 


5.6 GENERALIDADES DEL SISTEMA DE ARCHIVOS DE MINIX 


Al igual que cualquier otro sistema de archivos, el de MINIX debe enfrentar todas las cuestiones i 
acabamos de estudiar: debe asignar y liberar espacio para los archivos, seguir la pista a los bloques de 
disco y al espacio libre, proteger de alguna forma a los archivos contra el uso no autorizado, etc. En el 
resto del capítulo examinaremos de cerca el sistema de archivos de MINIX para ver cómo alcanza estos 
objetivos. 

En la primera parte del capítulo hicimos referencia una y otra vez a UNIX y no a MINIX en aras 
de la generalidad, aunque la interfaz externa de los dos es casi idéntica. Ahora nos concentraremos en el 
diseño interno de MINIX. Si el lector desea información acerca del diseño interno de UNIX puede 
consultar Thompson (1978), Bach (1987), Lions (1996) y Vahaba (1996). 

El sistema de archivos de MINIX es sólo un programa en C grande que se ejecuta en el espacio de 
usuario (véase la Fig. 2-26). Para leer y escribir archivos, los procesos de usuario envían mensajes al 
sistema de archivos indicándole lo que quieren que haga. El sistema de archivos efectúa el trabajo y luego 
devuelve una respuesta. De hecho, el sistema de archivos es un servidor de archivos en red que por 
casualidad se ejecuta en la misma máquina que el invocador. 

Este diseño tiene ciertas implicaciones importantes. Por un lado, podemos modificar el sistema de 
archivos, experimentar con él y probarlo con independencia casi total del resto de MINIX. Por el otro, es 
muy fácil trasladar todo el sistema de archivos a cualquier computadora que tenga un compilador de C, 
compilarlo ahí, y utilizarlo como servidor de archivos remoto autónomo tipo UNIX. Los únicos cambios 
que habría que efectuar serían en el área del mecanismo de envío y recepción de mensajes, que vana de un 
sistema a otro. 

Días siguientes secciones presentaremos una reseña de muchas de las áreas clave del diseño del 
sistema de archivos. Específicamente, examinaremos los mensajes, la organización del sistema de 
archivos, los mapas de bits, los nodos-i, el caché de bloques, los directorios y rutas, los 
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descriptores de archivo, los candados de archivo y los archivos especiales (más los conductos). Después 
de estudiar todos estos temas, mostraremos un ejemplo sencillo de cómo embonan las piezas rastreando lo 
que sucede cuando un proceso de usuario ejecuta la llamada al sistema READ. 


5,6.1 Mensajes 


El sistema de archivos acepta 39 tipos de mensajes que solicitan trabajo. Todos, menos dos, son para 
llamadas al sistema MINIX. Las dos excepciones son mensajes generados por otras partes de MINIX. De 
las llamadas al sistema, 31 se aceptan de procesos de usuario. Seis mensajes son para llamadas al sistema 
que son manejadas primero por el administrador de memoria, que luego llama al sistema de archivos para 
que efectúe una parte del trabajo. El sistema de archivos procesa también otros dos mensajes. Todos los 
mensajes se muestran en la Fig. 5-27. 

La estructura del sistema de archivos es básicamente la misma que la del administrador de 
memoria y todas las tareas de E/S. Hay un ciclo principal que espera la llegada de un mensaje, Cuando 
llega un mensaje, se extrae su tipo y se usa como índice para consultar una tabla que contiene apuntadores 
a los procedimientos dentro del sistema de archivos que se encargan de cada tipo de mensaje. Luego se 
invoca el procedimiento apropiado, el cual efectúa el trabajo y devuelve un valor de situación. A 
continuación, el sistema de archivos envía una respuesta de vuelta al invocador y regresa al principio de su 
ciclo para esperar el siguiente mensaje. 


5.6.2 Organización del sistema de archivos 


Un sistema de archivos MINIX es una entidad lógica y autónoma con nodos-i, directorios y bloques de 
datos. Este sistema puede almacenarse en cualquier dispositivo por bloques, como un disco flexible o (una 
porción de) un disco duro. En todos los casos, la organización del sistema de archivos tiene la misma 
estructura. En la Fig. 5-28 se muestra esta organización para un disquete de 360K con 128 nodos-i y un 
tamaño de bloque de 1K. Los sistemas de archivos más grandes, o aquellos con más o menos nodos-i o un 
tamaño de bloque distinto, tienen los mismos seis, componentes en el mismo orden, pero sus tamaños 
relativos podrían ser distintos. 

Todo sistema de archivos comienza con un bloque de arranque, el cual contiene código ejecutable. 
Cuando se enciende la computadora, el hardware lee el bloque de arranque del dispositivo de arranque y 
lo coloca en la memoria, salta a él y comienza a ejecutar su código. Este código inicia el proceso de cargar 
el sistema operativo mismo. Una vez puesto en marcha el sistema, no se usa más el bloque de arranque. 
No todas las unidades de disco pueden usarse como dispositivos de arranque, pero a fin de mantener 
uniforme la estructura, cada dispositivo de bloques lleva un bloque reservado para el código de arranque. 
En el peor de los casos,esta estrategia desperdicia un bloque. Con objeto de evitar que el hardware trate de 
arrancar con un dispositivo no de arranque, se coloca un número mágico en cierto lugar conocido del 
bloque de arranque si y sólo si el código ejecutable está escrito en el dispositivo. Al arrancar desde un 
dispositivo, el hardware (en realidad, el código BIOS) se negará a cargar de un dispositivo que 
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H*nu|M de usuarios 

ACCESS 

Parámetros de entrada 

Nombre de archivo, modo de acceso 

Valor de respuesta 

Estado 

ckxr 

Nombre del nuevo dnctono de trabafo 

Estado 

'ChMOD 

Nombre de archivo, nuevo modo 

Estado 

CMOWN 

Nombre de archero. nuevo Cuarto grupo 

Estado 

OflOOT 

Nomore del nuevo a reclono retí 

Estado 

aosc 

ícíüat 

Descriptor de archivo del archivo por cerrar 

Nombre dal archivo poi creer, mcdo 

Estado 

Descriptor da archivo_ 

\w _ 

ECNTl 

FSTAT 

Oescnptor de archivo (pera dup2, dos as.) 

Descriptor de archivo, códgo de toncton, arg 

Nombre de archivo buffet 

i Nuevo descriptor ds archivo 1 
! Depende de la fundón 

Estado 

¡I0CTL 

Oescnptor de archivo. oOdrgo de tuncmn, arg 

Estado 

UM< 

ISKK 

Archivo al cual enlaxar, nombre de enlace 

Oescnptor de archivo, distancia, de donde 

Estado 

Nueva posición 

mkdir 

Nomore de arctvvo, modo 

Estado 

WCMOO 

MOUNT 

fe* - - 

wE 

Nombre de dir o especal. modo dirección 

Archivo especial dOnde montar, bandera ro 

Nomore del archivo por abrir, bardara r,*w 

Apuntador a de» descriptores da archivo (modificado) 

i Estado 

Estado 

Descriptor ds archivo 

Estado 

~ — —j 

REAO 

RENAME 

Oescnptor da archivo, buhen cuantos bytea 

Nomore de archivo nomore de arctvvo 

Num. bytes isvdos 

Estado 

wom 

Nombre de arctvvo 

Estado 

STAT 

Nombre de archivo, bulfer de estado 

| Estado 

ST1ME_ __ 

Apuntador a hora actual 

Estado 

svwc 

(Ninguno) 

Siempre OK 

TIME 

Apuntador al lugai donde va la hora actual 

Estado 

TIMES _ 

IMAS» 

UMOUNT 

Wiw 1 

Apuntador a buhei pera tiempos de proceso e tv(o 
Complemento de máscara de modo 

Nombre de archvo especia* por desmontar 

Estado 

Siempre OK 

Estado 

Nombre del archivo por desenlazar 

Estado 

LTIME _ ^ 

Nombre de archivo, hempee de archivo 

Siempre OK 1 

WWTE 

Uru|<i ds MM 

Descriptor de archivo, buha» cuántos byles 

Parámetros de entrada 

Núm bytes escritos 

Valor de respuesta 

EXEC 

■f*. 

Esiad- 

EXIT 

Pía 

Estado 

fOW 

Pd dal padre, pid del hqo 

I Estado 

Yetgid 

Pid gid real y electivo 

Estado 

SETS ID 

P* 

Estado 

SETWD l 

Pd, uid real y efectivo 

Estado 

Ciros msnsajss 

Parámetros ds entrada 

Valor de respuesta 

REVINE 

Proceso por revivir 

(Sm respuesta) 

UNOAUSE 

Proceso por ventea- 

(Véase tarto) 


Figura 5-27. Mensajes del sistema de archivos. Los parámetros de nombre de archivo siem¬ 
pre son apuntadores al nombre. El código "situación" como valor de respuesta significa OKo 
ERROR. 
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no cuente con número mágico. Esto evita el empleo inadvertido de basura como programa de arranque. 


Bloque de Super 

arranque bloque Un bloque 

i / dec,ísco 

rrrrji 11111111 Pi 11111 rrrm 

/ \ Datos 

Mapa de bits Mapa de bits 

de nodos-i de zonas 


Figura 5-28. Organización del disco más sencillo: un disquete de 360K con 128 nodos-i y 
bloques de 1K (es decir, dos sectores consecutivos de 512 bytes se tratan como un solo 
bloque). 


El superblooque contiene información que describe la organización del sistema de archivos, y se 
ilustra en la Fig. 5-29. La función principal del superbioque es indicarle al sistema de archivos el tamaño 
de sus diversos componentes. Dado el tamaño de bloque y el número de nodos-i, es fácil calcular el 
tamaño del mapa de bits de nodos-i y el número de bloques de nodos-i. Por ejemplo, si los bloques son de 
1K, cada bloque de mapa de bits tiene 1K bytes (8K bits), así que puede indicar la situación de hasta 8192 
nodos-i. (De hecho, el primer bloque sólo puede manejar hasta 8191 nodos-i, ya que no existe el nodo-i 
cero, pero de todos modos hay un bit para él en el mapa.) Si hay 10 000 nodos-i, se necesitan dos bloques 
para el mapa de bits. Puesto que cada nodo-i ocupa 64 bytes, un bloque de 1K contiene hasta 16 nodos-i. 
Con 128 nodos-i utilizables, se requieren ocho bloques de disco para contenerlos todos. 

Explicaremos detalladamente la diferencia entre zonas y bloques más adelante, pero por ahora 
baste con decir que el espacio de almacenamiento en disco se puede asignar en unidades (zonas) de 1, 2, 4, 
8 o, en general, 2" bloques. El mapa de bits de zonas lleva la cuenta del espacio libre en términos de 
zonas, no de bloques. En todos los disquetes estándar empleados por MINIX el tamaño de zona y de 
bloque es el mismo (1K), así que como primera aproximación una zona es lo mismo que un bloque en 
estos dispositivos. Hasta que lleguemos a los detalles de la asignación de espacio de almacenamiento más 
adelante en este capítulo, podemos pensar "bloque" cada vez que veamos "zona". 

Cabe señalar que el número de bloques por zona no se almacena en el superbioque, ya que nunca 
se necesita. Lo único que se necesita es el logaritmo base 2 de la relación zona/bloque, que se usa como 
cuenta de desplazamiento para convertir zonas en bloques y viceversa. Por ejemplo, si hay , ocho bloques 
en cada zona, log A = 3, así que para encontrar la zona que contiene el bloque 1281 desplazamos 128 tres 
bits a la derecha para obtener la zona 16. 

El mapa de bits de zonas sólo incluye las zonas de datos (esto es, los bloques empleados para los 
mapas de bits y los nodos-i no están en el mapa), designándose a la primera zona de datos zona 1 en el 
mapa de bits. Al igual que con el mapa de bits de nodos-i, no se utiliza el bit O de este mapa, de modo que 
el primer bloque del mapa de zonas puede seguir la pista a 8191 zonas y los bloques 
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Presentes 
en el cisco 
y en la 
memoria 


Presentes 
en la mamona 
pero no 
en el disco 


Número de nodos 

Número de zonas (VI) 

Núm. bloques del mapa de nodos-i 

Num bloqes del mapa de zonas 

Primera zona de datos 

log^bloque/zona) 

- Tamaflo de archivo máximo 

Número mágico 

Relleno 

- Número de zonas (V2) 

_ Apuntador ai nodo-i de la raíz 
del sistema de archivos montado 

Apuntador al nodo-i 
sobre el que se montó 

Nodos-i/bioque 

Número de dispositivo 

Bandera de sólo lectura 

Bandera de FS big-endian 

Versión del sistema de archivos 

Zonas directasrnodo-i 

Zonas indirectas/bloque indirecto 

Primer bit líbre en mapa de nodos-i 

Primer bit líbre en mapa de zonas 


Figura 5-29. El superbloque de MINIX. 


subsecuentes pueden seguir la pista a 8192 zonas cada uno. Si examinamos los mapas de bits de un disco 
recién formateado, veremos que tanto el mapa de bits de nodos-i como el de zonas tienen dos bits 
encendidos (en 1). Uno es para el nodo-i o zona cero inexistente; el otro es para el nodo-i y la zona 
empleados por el directorio raíz del dispositivo, que se coloca ahí cuando se crea el sistema de archivos. 

La información que está en el superbioque es redundante porque a veces se necesita en una forma 
y a veces en otra. Con 1K dedicado al superbioque, es razonable calcular esta información su todas las 
formas en que se necesita, para no tener que recalcularla con frecuencia durante la ejecución. Por ejemplo, 
el número de zona de la primera zona de datos del disco se puede calcular a partir del tamaño de bloque, el 
tamaño de zona, el número de nodos-i y el número de zonas, pero timas fácil guardarlo simplemente en el 
superbioque. De todos modos, el resto del superbioque Se desperdicia, así que usar otra palabra de él no 
cuesta nada. 

Cuando se inicia MINIX, se lee el superbioque del dispositivo raíz y se coloca en una tabla en la 
memoria. De forma similar, conforme se montan los demás sistemas de archivos, sus bloques se traen 
también a la memoria. La tabla de superbioques contiene varios campos 
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que no están presentes en el disco. Éstos incluyen banderas que permiten especificar que un dispositivo es 
sólo de lectura (ro) o que sigue una convención de orden de bytes opuesta a la estándar, así como campos 
para agilizar el acceso indicando puntos de los mapas de bits por debajo de los cuales todos los bits están 
marcados como ocupados. Además, hay un campo que describe el dispositivo del cual provino el 
superbioque. 

Antes de que un disco pueda usarse como sistema de archivos de MINIX, se le debe imponer la 
estructura de la Fig. 5-28. Se incluye el programa mkfs para construir sistemas de archivos. Este programa 
puede invocarse ya sea con un comando como 


mkfs/dev/fd-1 1440 


para construir un sistema de archivos vacío de 1440 bloques en el disco flexible de la unidad 1, o se le 
puede proporcionar un archivo prototipo que lista los directorios y los archivos que deben incluirse en el 
nuevo sistema de archivos. Este comando también coloca un número mágico en el superbioque para 
identificar el sistema de archivos como sistema de archivos válido de MINIX. El sistema de archivos de 
MINIX ha evolucionado, y algunos aspectos de él (como el tamaño de los nodos-i) eran diferentes en las 
primeras versiones. El número mágico identifica la versión de mkfs que creó el sistema de archivos, para 
que puedan compensarse las diferencias. La llamada al sistema MOUNT rechazará los intentos por montar 
un sistema de archivos que no tenga el formato de MINIX, digamos un disquete MS-DOS. Esta llamada 
comprueba que el superbioque contenga un número mágico válido y otras cosas. 


5.6.3 Mapas de bits 


MINIX sabe cuáles nodos-i y zonas están libres gracias a dos mapas de bits (véase la Fig. 5-29). Cuando 
se elimina un archivo, es cosa sencilla calcular cuál bloque del mapa de bits contiene el bit que 
corresponde al nodo-i que se está liberando y encontrarlo empleando el mecanismo de caché normal. Una 
vez que se localiza ese bloque, el bit en cuestión se pone en 0. Las zonas se liberan del mapa de bits de 
zonas de la misma manera. 

Lógicamente, cuando se va a crear un archivo el sistema de archivos debe examinar los bloques 
del mapa de bits uñó por uno hasta encontrar el primer nodo-i libre. A continuación se asigna este nodo-i 
al nuevo archivo. De hecho, la copia del superbioque que está en la memoria tiene un campo que apunta 
al primer nodo-i libre, así que no se requiere una búsqueda sino hasta, después de que se usa un nodo, ya 
que entonces es necesario actualizar el apuntador de modo que, apunte al que ahora es el siguiente nodo-i 
libre, el cual muchas veces resulta ser el siguiente, o uno muy cercano. De forma similar, cuando se libera 
un nodo-i, se averigua si este nodo va antes de aquel al que actualmente se está apuntando, y se actualiza 
el apuntador si es necesario. Si todas las ranuras de nodo-i del disco están llenas, la rutina de búsqueda 
devuelve un cero, y ésta es la razón por la que no se usa el nodo-i cero (es decir, para que pueda usarse 
para indicar que la búsqueda fracasó). (Cuando mkfs crea un nuevo sistema de archivos, pone en ceros el 
nodo-i cero y pone en 1 el bit más bajo del mapa de bits, a fin de que el sistema de archivos nunca intente 
asignarlo.) Todo lo que hemos dicho aquí acerca de los mapas de bits de nodos-i también aplica al mapa 
de bits de zonas; se efectúa una búsqueda lógica de la primera zona libre cuando se necesita espacio, 
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pero se mantiene un apuntador a la primera zona libre con objeto de eliminar casi por completo la 
necesidad subsecuente de efectuar búsquedas secuenciales en el mapa de bits. 

Con estos antecedentes, ya podemos explicar la diferencia entre zonas y bloques. La razón para 
tener zonas es ayudar a que los bloques de disco que pertenecen al mismo archivo se encuentren en el 
mismo cilindro, a fin de mejorar el rendimiento cuando el archivo se lee secuencialmente. La estrategia 
que se escogió hace posible asignar varios bloques a la vez. Por ejemplo, si el tamaño de bloque es de 1K 
y el tamaño de zona es de 4K, el mapa de bits de zonas sigue la pista a las zonas, no a los bloques. Un 
disco de 20M tiene 5K zonas de 4K, y por tanto 5K bits en su mapa de zonas. 

La mayor parte del sistema de archivos funciona por bloques. Las transferencias de disco siempre 
se efectúan un bloque a la vez, y el caché de buffer también trabaja con bloques individuales. Sólo unas 
cuantas partes del sistema que se ocupan de direcciones físicas en disco (p. ej., el mapa de bits de zonas y 
los nodos-i) saben de la existencia de zonas. 

Tuvieron que tomarse ciertas decisiones de diseño al crear el sistema de archivos de MINIX. En 
1985, cuando se concibió MINIX, la capacidad de los discos era pequeña, y se esperaba que muchos 
usuarios sólo tendrían discos flexibles. Se tomó la decisión de restringir las direcciones en disco aló bits 
en el sistema de archivos VI, principalmente para poder almacenar muchas direcciones en los bloques 
indirectos. Con un número de zona de 16 bits y zonas de 1K, sólo es posible direccionar 64K zonas, lo que 
limita los discos a 64M. Ésta era una cantidad enorme de espacio de almacenamiento en aquellos días, y 
se pensaba que al aumentar el tamaño de los discos sería fácil cambiar a zonas de 2K o 4K, sin tener que 
cambiar el tamaño de bloque. Los números de zona de 16 bits también han facilitado mantener el tamaño 
de los nodos-i en 32 bytes. 

Conforme se fue desarrollando MINIX, y los discos grandes se volvieron más comunes, se hizo 
evidente la necesidad de efectuar cambios. Muchos archivos son más pequeños que 1K, así que aumentar 
el tamaño de bloque implicaría desperdiciar ancho de banda del disco, leyendo y escribiendo bloques en 
su mayor parte vacíos y desperdiciando valiosa memoria principal al guardarlos en el caché de buffer. Se 
podía haber aumentado el tamaño de zona, pero esto habría | implicado más espacio de disco 
desperdiciado, y seguía siendo deseable retener un fúncionamiento eficiente en los discos pequeños. Otra 
alternativa razonable habría sido tener diferentes tamaños de zona en los dispositivos grandes y en los 
pequeños. 

Al final se decidió aumentar el tamaño de los apuntadores a disco a 32 bits. Esto permite al 
sistema de archivos MINIX V2 manejar dispositivos de hasta 4 terabytes en términos de bloques y zonas 
de 1K. En parte, esta decisión fue consecuencia de otras decisiones relativas al contenido de los nodos-i 
que hicieron justificable aumentar el tamaño de nodo-i a 64 bytes. 

Las zonas también introducen un problema inesperado, que podemos explicar mejor con la ayuda 
de un ejemplo sencillo en el que otra vez suponemos zonas de 4K y bloques de 1 K. Supongamos que un 
archivo tiene una longitud de 1K, lo que implica que se le asignó una zona. Los bloques entre 1K y 4K 
contienen basura (residuo del propietario anterior), pero no hay problema porque el tamaño del archivo 
está claramente marcado en el nodo-i como 1K. De hecho, los bloques que contienen basura no se colocan 
en el caché de bloques, ya que las lecturas se efectúan por bloques, no por zonas. Las lecturas más allá del 
final de un archivo siempre devuelven una cuenta de 0 y nada de datos. 
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Ahora alguien realiza un SEEK a 32768 y escribe un byte. El tamaño del archivo cambia ahora a 
32769. Los SEEK subsecuentes a 1K seguidos de intentos por leer los datos podrán leer ahora el 
contenido previo del bloque, lo cual es una violación grave de la seguridad. 

La solución es vigilar la ocurrencia de esta situación cuando se realiza una escritura más allá del 
final de un archivo, y poner explícitamente en cero todos los bloques que todavía no se han asignado en la 
zona que previamente era la última. Aunque esta situación rara vez ocurre, el código tiene que preverla, lo 
que lo hace un poco más complejo. 


5.6,4 Nodos-i 


La organización del nodo-i de MINIX se da en la Fig. 5-30, y es casi idéntica a la de un nodo-i estándar de 
UNIX. Los apuntadores a zonas de disco tienen 32 bits, y sólo hay nueve apuntadores, siete directos y dos 
indirectos. Los nodos-i de MINIX ocupan 64 bytes, lo mismo que los nodos-i UNIX estándar, y hay 
espacio disponible para un décimo apuntador (de triple indirección), aunque su uso no está contemplado 
en la versión estándar del sistema de archivos. Los tiempos de acceso a nodo-i, modificación y cambio de 
nodo-i en MINIX son estándar, igual que en UNIX. El último de éstos se actualiza en casi cada operación 
con el archivo, con excepción de la lectura. 

Cuando se abre un archivo, se localiza su nodo-i y se trae a la tabla inode en la memoria, donde 
permanece hasta que se cierra el archivo. Esta tabla tiene unos cuantos campos adicionales que no están 
presentes en el disco, como el dispositivo y número del nodo-i, con objeto de que el sistema de archivos 
sepa dónde debe reescribirlo si se modifica mientras está en la memoria. La tabla también tiene un 
contador por cada nodo-i. Si el mismo archivo se abre más de una vez, sólo se guardará en la memoria una 
copia del nodo-i, pero el contador se incrementará cada vez que el archivo se abra y se decrementará cada 
vez que se cierre. Sólo si el contador llega a cero se retira el nodo-i de la tabla, Si el nodo se modificó 
después de que se cargó en la memoria, también se reescribe en el disco. 

La fúnción principal del nodo-i de un archivo es indicar dónde están los bloques de datos. Los 
primeros siete números de zona están en el nodo-i mismo. En la distribución estándar, con zonas bloques 
de 1K, los archivos de hasta 7K no necesitan bloques de indirección. Más allá de 7K se requieren zonas de 
indirección, empleando el esquema de la Fig. 5-10, excepto que sólo se usan los bloques de indirección 
sencilla y doble. Con bloques y zonas de 1 K y números de zona de 32 bits, un solo bloque indirecto 
contiene 256 entradas, lo que representa un cuarto de megabyte de almacenamiento. El bloque de doble 
indirección apunta a 256 bloques de indirección sencilla, dando acceso a hasta 64 megabytes. El tamaño 
máximo de un sistema de archivos MINIX es de 1 G, así que una modificación para usar el bloque de 
triple indirección o zonas más grandes podría ser útil si fúera deseable acceder a archivos muy grandes en 
un sistema MINIX. 

El nodo-i también contiene la información de modo, que indica el tipo de archivo de que se trata 
(normal, de directorio, especial por bloques, especial por caracteres o conducto), y da los bits de 
protección y de SETUID y SETGID. El campo li nk (enlace) del nodo-i registra el numeral de entradas de 
directorio que apuntan al nodo-i, y permite al sistema de archivos saber cuándo debe liberar el espacio que 
ocupa el archivo. No debe confúndirse este campo con el contador (presente sólo en la tabla inode en la 
memoria, no en el disco) que indica cuántas veces está abierto actualmente el archivo, casi siempre por 
procesos distintos. 
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letxis 


Modo 
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Números de zona 
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Empleados para archivos 
que ocupan más de 7 zonas 


(Podría usarse para zona triple indirecta) 


5.6.5 El caché de bloques 


MINIX emplea un caché de bloques para mejorar el rendimiento del sistema de archivos. El caché 
seimplementa como arreglo de buffers, cada uno formado por un encabezado que contiene apuntadores, 
contadores y banderas, y un cuerpo con espacio para un bloque de disco. Todos los buffers que no se están 
usando se encadenan en una lista doblemente enlazada, desde el más recientemente te utilizado (MRU) 
hasta el menos recientemente utilizado (LRU), como se ilustra en la Fig. 5-31. 
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Además, se emplea una tabla hash (o de cálculo de clave) para determinar con rapidez si un 
bloque dado está en el caché o no. Todos los buffers que contienen un bloque con el código hash k se 
encadenan en una lista enlazada sencilla a la que apunta la entrada k de la tabla hash. La función hash 
simplemente extrae los n bits de orden bajo del número de bloque, de modo que bloques de diferentes 
dispositivos aparecen en la misma cadena hash. Cada uno de los buffers está en alguna de estas cadenas. 
Desde luego, cuando se inicializa el sistema de archivos después de iniciarse MINIX, todos los buffers 
están desocupados, y todos están en una sola cadena a la que apunta la entrada cero de la tabla hash. En 
ese momento, todas las demás entradas de la tabla hash contienen un apuntador nulo, pero tan pronto 
como el sistema se pone en marcha se retiran buffers de la cadena cero y se construyen otras cadenas. 

Cuando el sistema de archivos necesita un bloque, invoca un procedimiento, getblock, que 
calcula el código hash para ese bloque y examina la lista apropiada. Se invoca get block con un número 
de dispositivo además de un número de bloque, y la búsqueda compara ambos número con los campos 
correspondientes en la cadena de buffers. Si se encuentra un buffer que contenaga el bloque, se incrementa 
un contador en el encabezado del buffer para indicar que el bloque en uso, y se devuelve un apuntador a 
él. Si no se encuentra un bloque en la lista hash, se pi usar el primer buffer de la lista LRU; se garantiza 
que ya no se está usando, y el bloque contiene se puede desalojar para liberar el buffer. 

Una vez que se escoge el bloque por desalojar, se revisa otra bandera de su encabezado ver si el 
bloque ha sido modificado desde que se trajo al caché. De ser así, el bloque se reescriben el disco. En este 
punto se lee del disco el bloque requerido enviando un mensaje a la tarea disco. El sistema de archivos 
queda suspendido hasta que llega el bloque, y entonces contini devolviendo al invocador un apuntador al 
bloque. 

Una vez que el procedimiento que solicitó el bloque termina su trabajo, invoca otro pnx miento, 
put block, para liberar el bloque. Normalmente, un bloque se usará de inmediato y li se liberará, pero 
como es posible que se presenten solicitudes adicionales para un bloque ante ser liberado, putJblock 
decrementa el contador de usos y coloca el buffer de vuelta en la LRU sólo cuando el contador de usos ha 
regresado a cero. Mientras el contador sea disti cero, el bloque permanecerá en el limbo. 
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Uno de los parámetros de putJblock indica qué clase de bloque (p. ej., nodos-i, directorio, datos) se está 
liberando. Dependiendo de la clase, se toman dos decisiones clave: 

1. Si se debe poner el bloque al frente o al final de la lista LRU. 

2. Si se debe escribir el bloque (si se modificó) en el disco inmediatamente o no. Los bloques con baja 
probabilidad de que se necesiten otra vez pronto, como los superbioques, pasan al frente de la lista con 
objeto de que sean reclamados la próxima vez que se necesite un buffer libre. Todos los demás bloques 
pasan al final de la lista según el régimen LRU estricto. Un bloque modificado no se reescribe hasta que 
ocurre uno de dos sucesos: 

1. El bloque llega al frente de la cadena LRU y es desalojado. 

2. Se ejecuta una llamada al sistema SYNC. 

SYNC no recorre la cadena LRU, sino que recorre con la ayuda de un índice el arreglo de buffers que 
están en el caché. Incluso si un buffer no se ha liberado todavía, si ha sido modificado SYNC lo 
encontrará y se asegurará de que se actualice la copia en disco. 

Sin embargo, hay una excepción. Un superbioque modificado se escribe en el disco de inmediato. 
En una versión anterior de MINIX se modificaba un superbioque cuando se montaba un sistema de 
archivos, y el propósito de la escritura inmediata era reducir la posibilidad de corromper el sistema de 
archivos en caso de una caída. Los superbioques ya no se modifican, así que el: código para escribirlos de 
inmediato es un anacronismo. En la configuración estándar, ningún j Otro bloque se escribe 
inmediatamente. Sin embargo, si se modifica la definición por omisión de E ROBUSTen el archivo de 
configuración del sistema, include/minix/config.h, se puede compilar el I sistema de archivos de modo que 
marque los bloques de nodos-i, directorio, indirección y mapa de bits de modo que se escriban tan pronto 
como sean liberados. El propósito de esto es hacer el iiistema de archivos más robusto; el precio que se 
paga es un funcionamiento más lento. El que esta medida sea provechosa o no es incierto. Una falla en la 
alimentación eléctrica en un momento fi el que todavía no se han escrito todos los bloques va a causar 
dolores de cabeza, sea que se ¡pierda un bloque de nodos-i o de datos. 

Cabe señalar que el procedimiento dentro del sistema de archivos que solicitó y usó el bloque i el 
que enciende la bandera del encabezado que indica que el bloque fue modificado. Los cedimientos 
getblock y put block sólo se ocupan de manipular las listas enlazadas; no tienen 1 de cuál procedimiento 
del sistema quiere cuál bloque, o por qué. 


5.6.6 Directorios y rutas 


Otro subsistema importante dentro del sistema de archivos es la administración de directorios y nombres 
de ruta. Muchas llamadas al sistema, como OPEN tienen un nombre de archivo como parámetro. Lo que 
realmente se necesita es el nodo-i de ese archivo, así que toca al sistema de archivos buscar el archivo en 
el árbol de directorios y localizar su nodo-i. 

Un directorio MINIX consiste en un archivo que contiene entradas de 16 bytes. Los dos primeros 
bytes forman un número de nodo-i de 16 bits, y los 14 bytes restantes son el nombre de 
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archivo. Esto es idéntico a la entrada de directorio UNIX tradicional que vimos en la Fig. 5-1 Para buscar 
la ruta /usr/ast/mbox, el sistema primero busca usr en el directorio raíz, luego busast en /usr, y por último 
busca mbox en /usr/ast. La búsqueda real se efectúa de componente componente de la ruta, como se ilustró 
en la Fig. 5-14. 

La única complicación es qué sucede cuando se encuentra un sistema de archivos montac La 
configuración usual en MINIX y muchos otros sistemas tipo UNIX es tener un sistema de arel vos raíz 
pequeño que contiene los archivos necesarios para iniciar el sistema y efectuar tare fundamentales de 
mantenimiento del sistema, y tener la mayor parte de los archivos, incluidos 1 directorios de usuarios, en 
un dispositivo aparte montado en /usr. Éste es un buen momento pa ver cómo se monta un dispositivo. 
Cuando el usuario teclea el comando 

mount /dev/hd2c /usr 

en la terminal, el sistema de archivos contenido en la partición 2 del disco duro se monta encin de /usr en 
el sistema de archivos raíz. Los sistemas de archivos antes y después del montado muestran en la Fig. 5- 
32. 


Sistema de 
archivos raíz 



(a) 


Sistema de archivos 
oo montado 



(t» 


Después 
de montar 




Figura 5-32. (a) Sistema de archivos raíz, (b) Un sistema de archivos no montado, (c) El 
resultado de montar el sistema de archivos de (b) en /usr. 


La clave del asunto de montar dispositivos es una bandera que se enciende en la copia del nodo-i 
de /usr que está en la memoria después de que se logró montar con éxito el sistema de archivos. Esta 
bandera indica que el nodo-i tiene un sistema de archivos montado en él. La llamada MOUNT también 
carga el superbioque del sistema de archivos recién montado en la tahsuper block y establece dos 
apuntadores en ella; además, coloca el nodo-i raíz del sistema iarchivos montado en la tabla inode. 
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En la Fig. 5-29 vemos que los superbioques en la memoria contienen dos campos relacionados 
con los sistemas de archivos montados. El primero de éstos, i-node-of-the-mounted-file-system, se ajusta 
de modo que apunte al nodo-i raíz del sistema de archivos que se acaba demontar. El segundo, i-node- 
mounted-on, se ajusta de modo que apunte al nodo-i en el cual se montó el sistema, que en este caso es el 
nodo-i de /usr. Estos dos apuntadores sirven para conectar el sistema de archivos montado a la raíz y 
representan el "adhesivo" que mantiene unido del sistema de archivos montado a la raíz [lo que se indica 
con puntos en la Fig. 5-32(c)j. Este adhesivo es lo que hace que funcionen los sistemas de archivos 
montados. 

Cuando se está buscando una ruta como /usr/ast/fZ, el sistema de archivos ve una bandera en el 
nodo-i de /usr y se da cuenta de que debe continuar buscando en el nodo-i raíz del sistema de archivos 
montado en /usr. La pregunta es, "¿cómo encuentra este nodo-i raíz?" 

La respuesta es sencilla. El sistema examina todos los superbioques que están en la memoria hasta 
encontrar aquel cuyo campo i-node mounted on apunta a /usr. Éste debe ser el superbioque del sistema de 
archivos montado en /usr. Una vez que se tiene el superbioque, es fácil seguir el otro apuntador para 
encontrar el nodo-i raíz del sistema de archivos montado. Ahora el sistema de archivos puede continuar la 
búsqueda. En este ejemplo, buscará ast en el directorio raíz de la partición 2 del disco duro. 


5.6.7 Descriptores de archivos 


Una vez que se ha abierto un archivo, se devuelve un descriptor de archivo al proceso de usuario para que 
lo use en las llamadas READ y WRITE subsecuentes. En esta sección veremos cómo se administran los 
descriptores de archivo dentro del sistema de archivos. 

Al igual que el kemel y el administrador de memoria, el sistema de archivos mantiene parte de la 
tabla de procesos dentro de su espacio de direcciones. Tres de los campos tienen un interés especial. Los 
primeros dos son apuntadores a los nodos-i del directorio raíz y del directorio de trabajo. Las búsquedas 
de rutas, como la de la Fig. 5-14, siempre comienzan en uno o en el otro, dependiendo de si la ruta es 
absoluta o relativa. Estos apuntadores se modifican con las llamadas al sistema CHROOT y CHDIR de 
modo que apunten al nuevo directorio raíz o al nuevo directorio de trabajo, respectivamente. 

El tercer campo interesante de la tabla de procesos es un arreglo indizado por número de 
descriptor de archivo, y sirve para localizar el archivo correcto cuando se presenta un descriptor de 
archivo. A primera vista, podría parecer que basta con hacer que la k-ésima entrada de este arreglo apunte 
al nodo-i del archivo que pertenece al descriptor de archivo k. Después de todo, el ¡ nodo-i se trae a la 
memoria cuando se abre el archivo y se mantiene ahí hasta que el archivo se cierra, así que siempre está 
disponible. 

Desafortunadamente, este sencillo plan falla porque los archivos se pueden compartir de formas 
sutiles en MINIX (lo mismo que en UNIX). El problema surge porque cada archivo tiene 1 asociado un 
número de 32 bits que indica el siguiente byte que se leerá o escribirá. Es este número, llamado posición 
en el archivo, lo que se modifica con la llamada al sistema LSEEK. El problema puede plantearse 
fácilmente: "¿dónde debe guardarse el apuntador al archivo?" 
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La primera posibilidad es colocarlo en el nodo-i. Lo malo es que si dos o más procesos tienen el 
mismo archivo abierto al mismo tiempo, todos deben tener sus propios apuntadores al archivo, ya que 
difícilmente sería aceptable que un LSEEK efectuado por un proceso afectara la siguiente lectura de un 
proceso distinto. Conclusión: la posición en el archivo no puede colocarse en el nodo-i. 

¿Y si la colocamos en la tabla de procesos? ¿Por qué no tener un segundo arreglo, paralelo al 
arreglo de descriptores de archivo, que indique la posición actual en cada archivo? Esta idea tampoco 
funciona, pero la razón es más sutil. Básicamente, el problema tiene su origen en la semántica de la 
llamada al sistema FORK. Cuando un proceso bifurca, tanto el padre como el hijo deben compartir un 
mismo apuntador que indique la posición actual en cada archivo abierto. 

Para entender mejor el problema, consideremos el caso de un guión de shell cuya salida se ha 
redirigido a un archivo. Cuando el shell bifurca el primer programa, su posición en el archivo para la 
entrada estándar es 0. Después, el hijo hereda esta posición y escribe, digamos, 1K de salidas, Cuando el 
hijo termina, la posición compartida en el archivo debe ser 1K. 

Ahora el shell lee otro poco del guión de shell y bifurca otro hijo. Es indispensable que el segundo 
hijo herede del shell una posición en el archivo de 1K, para que comience a escribir en; el lugar en el que 
se quedó el primer programa. Si el shell no compartiera la posición en el archivo con sus hijos, el segundo 
programa sobreescribiría las salidas del primero, en lugar de anexar sus salidas alas de él. 

En consecuencia, no es posible colocar la posición en el archivo en la tabla de procesos; en 
realidad debe compartirse. La solución que se emplea en MINIX es introducir una nueva tablar 
compartida, A //?, que contiene todas las posiciones en los archivos. Su uso se ilustra en la Fig. 5-3S[j Al 
compartir realmente la posición en el archivo, la semántica de FORK se puede implementar 
correctamente, y los guiones de shell funcionan como es debido. 


Tabla 

Tabla «ilp de nodosn 



Figura 5-33. Cómo se comparten las posiciones en el archivo entre un padre y un hijo. 


Aunque la única cosa que debe contener realmente la tabla filp es la posición en el i compartida, 
es aconsejable colocar también el apuntador al nodo-i ahí. De este modo, lo único que tiene el arreglo del 
descriptor de archivo en la tabla de procesos es un apuntador a una entrada 
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i/p. La entrada filp también contiene el modo del archivo (bits de permiso), algunas banderas que ndican si 
el archivo se abrió en un modo especial, y una cuenta del número de procesos que lo istán usando, para 
que el sistema de archivos pueda saber cuándo ha terminado el último proceso A ue estaba usando esa 
entrada, a fin de recuperar la ranura. 


5.6.8 Candados de archivos 


Hay un aspecto más de la administración de sistemas de archivos que requiere una tabla especial. Se trata 
de los candados de archivos. MINIX apoya el mecanismo de comunicación entre procesos POSK de 
candados de archivo consultivos. Esto permite que cualquier parte, o varias partes, de un archivo se 
marquen como "aseguradas". El sistema operativo no obliga a respetar los candados, pero se espera que 
los procesos se porten bien y determinen si un archivo tiene o no candados antes de hacer algo que pudiera 
causar un conflicto con otro proceso. 

Las razones para contar con una tabla aparte para los candados son similares a las justificaciones 
de la tabla filp que vimos en la sección anterior. Un solo proceso puede tener más de un ¡eandado activo, y 
diferentes partes de un archivo pueden ser aseguradas por más de un proceso tinque, por supuesto, los 
candados no pueden traslaparse), así que ni la tabla de procesos ni la iAifilp son buenos lugares para 
asentar los candados. Puesto que se puede poner más de un indado a un archivo, el nodo-i tampoco es un 
buen lugar. 

MINIX emplea otra tabla, file lock, para registrar todos los candados. Cada ranura de esta tía 
tiene espacio para guardar el tipo del candado, que indica si el archivo está asegurado contra ira o contra 
escritura, el identificador del proceso que posee el candado, un apuntador al )-i del archivo asegurado, y 
las distancias a las que están el primero y el último byte de la ín asegurada. 


S.9 Conductos y archivos especiales 


Los conductos y los archivos especiales difieren de los archivos ordinarios en un aspecto importante, 
dando un proceso trata de leer de, o escribir en, un archivo en disco, no hay duda de que la acción se 
completará en unos cuantos cientos de milisegundos como máximo. En el peor de casos, podrían 
necesitarse dos o tres accesos a disco, no más. Al leer de un conducto, la sitúales diferente: si el conducto 
está vacío, el lector tendrá que esperar hasta que algún otro proBcoloque datos en él, lo cual podría tardar 
horas. Asimismo, al leer de una terminal, un procera que esperar hasta que alguien teclee algo. 

Por tanto, la regla normal que tiene el sistema de archivos de atender una solicitud hasta ir no 
fúnciona aquí. Es necesario suspender las solicitudes y reiniciarias después. Cuando «so trata de leer de, o 
escribir en, un conducto, el sistema de archivos puede verificar el del conducto de inmediato para ver si la 
operación puede completarse. Si se puede, se ¡ta, pero si no, el sistema de archivos registra los parámetros 
de la llamada al sistema en la e procesos, a fin de poder reiniciar el proceso cuando llegue el momento. 

Cabe señalar que el sistema de archivos no necesita emprender acción alguna para hacer que el 
irse suspenda; lo único que tiene que hacer es no enviar una respuesta, dejando al invocador 
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bloqueado esperándola. Así pues, después de suspender un proceso, el sistema de archivos regresa a su 
ciclo principal para esperar la siguiente llamada al sistema. Tan pronto como otro proceso modifica el 
estado del conducto de modo tal que el proceso suspendido ya puede completar la operación, el sistema de 
archivos iza una bandera para que en la siguiente iteración del ciclo principal extraiga de la tabla de 
procesos los parámetros del proceso suspendido y ejecute la llamada. 

La situación con las terminales y otros archivos especiales por caracteres es un poco distinta. El 
nodo-i de cada archivo especial contiene dos números, el dispositivo principal y el dispositivo secundario. 
El número de dispositivo principal indica la clase del dispositivo (p. ej., disco en RAM, disquete, disco 
duro, terminal) y se usa como índice para consultar una tabla del sistema de archivos que lo transforma en 
el número de la tarea correspondiente (es decir, controlador de E/S). En efecto, el dispositivo principal 
determina cuál controlador de E/S debe invocarse. El número de dispositivo secundario se pasa al 
controlador como parámetro, y especifica cuál dispositivo debe usarse, por ejemplo, la terminal 2 o la 
unidad de disco 1. 

En algunos casos, sobre todo los dispositivos terminales, el número de dispositivo secundario 
codifica cierta información referente a una categoría de dispositivos manejados por una tarea. Por 
ejemplo, la consola primaria de MINIX, /dev/console, es el dispositivo 4, O (principal, secundario). Las 
consolas virtuales son manejadas por la misma parte del controlador en software. Éstas son los 
dispositivos /dev/ttycl (4, l),/dev/ttyc2 (4, 2), etc. Las terminales de línea serial requieren software de bajo 
nivel distinto, y estos dispositivos, /dev/ttyOO y /dev/ttyOl tienen asignados los números de dispositivo 4, 
16 y 4, 17. Asimismo, las term in ales de red emplean controladores de seudotenninal, |y también necesitan 
software de bajo nivel diferente. En MINIX se asigna a estos dispositivos, ttypO, jttypl, etc., números tales 
como 4, 128 y 4, 129. Cada uno de estos seudodispositivos tiene asociado" un dispositivo, ptypO, ptypl, 
etc. Los pares de número de dispositivo principal y secundario para éstos son 4,192,4,193, etc. Se escogen 
los números de modo que sea fácil para la tarea controladoB;|invocar las funciones de bajo nivel 
requeridas para cada grupo de dispositivos; no se espera que| lguien vaya a equipar un sistema MINIX con 
192 ter mi nales o más. 

Cuando un proceso lee de un archivo especial, el sistema de archivos extrae los números de 
dispositivo principal y secundario del nodo-i del archivo, y utiliza el número de dispositivo prins pal como 
índice de una tabla propia para transformarlo en el número de tarea correspondient Una vez que tiene el 
número de tarea, el sistema de archivos envía un mensaje a esa tatq incluyendo como parámetros el 
número de dispositivo secundario, la operación por realizara número de proceso y dirección de buffer del 
invocador, y el número de bytes por transferir.) formato es el mismo que el de la Fig. 3-15, excepto que no 
se usa POSITION. 

Si el controlador puede efectuar el trabajo de inmediato (p. ej., si ya se tecleó una lineal entradas 
en la terminal), copia los datos de sus propios buffers internos al usuario y envía al sistema de archivos un 
mensaje de respuesta indicándole que se completó el trabajo. El sisti archivos envía entonces un mensaje 
de respuesta al usuario, y la llamada termina. Cabe que el controlador no copia los datos en el sistema de 
archivos. Los datos de dispositiv bloques pasan por el caché de bloques, pero los datos de los archivos 
especiales por caracte. 

Por otro lado, si el controlador no puede llevar a cabo el trabajo, asienta los parámeü mensaje en 
sus tablas internas y de inmediato envía una respuesta al sistema de archivos (dolé que no se pudo 
completar la llamada. En este punto, el sistema de archivos está en la) 
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situación en la que está cuando descubre que alguien está tratando de leer de un conducto vacío; toma nota 
del hecho de que el proceso está suspendido y espera el siguiente mensaje. 

Una vez que el controlador ha adquirido suficientes datos para completar la llamada, los transfiere 

al buffer del usuario que todavía está bloqueado y luego envía al sistema de archivos un mensaje para informarle de 
lo que hizo. Lo único que tiene que hacer el sistema de archivos es enviar un mensaje de respuesta al usuario para 
desbloquearlo e informar el número de bytes transferidos. 


5.6.10 Un ejemplo: La llamada al sistema READ 


Como veremos en breve, la mayor parte del código del sistema de archivos se dedica a llevar a cabo 
llamadas al sistema. Por tanto, es conveniente concluir esta reseña con un breve bosquejo de cómo 
funciona la llamada más importante, READ. 

Cuando un programa de usuario ejecuta la instrucción 
n=read(fd, buffer, nbytes); 

para leer un archivo ordinario, se invoca el procedimiento de biblioteca read con tres parámetros. Este 
procedimiento construye un mensaje que contiene estos parámetros, junto con el código para READ como 
tipo de mensaje, envía el mensaje al sistema de archivos, y se bloquea esperando la respuesta. Cuando 
llega el mensaje, el sistema de archivos usa el tipo de mensaje como índice de sus tablas para obtener el 
nombre del procedimiento que se encarga de leer, e invocarlo. 

Este procedimiento extrae el descriptor de archivo del mensaje y lo utiliza para localizar la entrada 
filp y luego el nodo-i del archivo que se va a leer (véase la Fig. 5-33). A continuación I la solicitud se 
divide en fragmentos de modo que cada uno quepa en un bloque. Por ejemplo, si la | posición actual en el 
archivo es 600 y se solicitaron 1K bytes, la solicitud se divide en dos partes, |de600 a 1023 y de 1024 a 
1623 (suponiendo bloques de 1K). 

Para cada uno de estos fragmentos, se verifica si el bloque pertinente está en el caché. Si el ique 
no está presente, el sistema de archivos escoge el buffer menos recientemente utilizado e no está 
actualmente en uso y lo toma, enviando un mensaje a la tarea del disco para que lo sscriba si está sucio. 
Luego se pide a la tarea de disco que obtenga el bloque que se va a leer. Una vez que el bloque está en el 
caché, el sistema de archivos envía un mensaje a la tarea del ma pidiéndole que copie los datos en el lugar 
apropiado del buffer del usuario (es decir, los s600 a 1023 al principio del buffer, y los bytes 1024 a 1623 
a una distancia de 424 dentro delér). Una vez efectuado el copiado, el sistema de archivos envía un 
mensaje de respuesta al trio especificando el número de bytes que se copiaron. 

Cuando la respuesta llega al usuario, la función de biblioteca read extrae el código de respuesta H 
lo devuelve como valor de la función al invocador. Hay un paso más que no forma parte realmente de la 
llamada READ misma. Una vez que el la de archivos completa una lectura y envía una respuesta, inicia 
una lectura del siguiente le, siempre que la lectura se haya hecho en un dispositivo por bloques y que se 
satisfagan s condiciones adicionales. Puesto que las lecturas de archivos secuenciales son comunes, 
esrazonable esperar que en la siguiente solicitud de lectura se pida el siguiente bloque del archivo, B 
aumenta la probabilidad de que el bloque deseado ya esté en el caché cuando se solicite. 



470 


SISTEMAS DE ARCHIVOS 


CAP. 5 


5.7 IMPLEMENTACIÓN DEL SISTEMA DE ARCHIVOS MINIX 


El sistema de archivos MINIX es relativamente grande (más de 100 páginas de C) pero muy sencillo. 
Llegan solicitudes para efectuar llamadas al sistema, se atienden, y se envían respuestas. En las siguientes 
secciones examinaremos el sistema archivo por archivo, destacando los puntos clave. El código mismo 
contiene muchos comentarios que ayudarán al lector. 

Al examinar el código de otras partes de MINIX generalmente hemos visto primero el ciclo 
principal de un proceso y luego las rutinas que se encargan de los diferentes tipos de mensajes. 
Abordaremos el sistema de archivos de forma distinta. Primero estudiaremos los principales subsistemas 
(administración de caché, administración de nodos-i, etc.), y luego examinaremos el ciclo principal y las 
llamadas al sistema que operan con archivos. Después veremos las llamadas al sistema que operan con 
directorios, y por último las llamadas que no pertenecen a ninguna de esas dos categorías. 


5.7.1 Archivos de encabezado y estructuras de datos globales 


Al igual que con el kemel y el administrador de memoria, varias estructuras de datos y tablas utilizadas en 
el sistema de archivos se definen en archivos de encabezado. Algunas de estas estructuras de datos se 
colocan en archivos de encabezado en el nivel del sistema, en include/y sus subdirectorios. Por ejemplo, 
include/sys/stat.h define el formato en el cual las llamadas al sistema pueden proporcionar información de 
nodos-i a otros programas, y la estructura de una entrada de directorio se define en include/sys/dir.h. 
POSIX exige estos dos archivos. Varias definiciones contenidas en el archivo de configuración global 
include/minix/config.h afectan el sistema de archivos, como la macro ROBUSTque define si las 
estructuras de datos importantes del sistema de archivos siempre se escribirán de inmediato o no en el 
disco, y NR BUFS y NR BUF HASH, que controlan el tamaño del caché de bloques. 


Encabezados del sistema de archivos 


Los archivos de encabezado propios del sistema de archivos están en el directorio fuente del FS src/fs/. 
Muchos nombres de archivo seguramente resultarán conocidos después de estudiar otras; partes del 
sistema MINIX. El archivo de encabezado maestro del FS,fs.h (línea 19400), es muyi similar a 
src/kemel/kemel.h y src/mm/mm.h; incluye otros archivos de encabezado que todos lo», archivos fuente 
en C del sistema de archivos necesitan. Al igual que en las demás partes de MINH el encabezado maestro 
del sistema de archivos incluye los archivos const.h, type.h, proto.h\ glo.h propios de este sistema. 
Veremos éstos a continuación. 

Const.h (línea 19500) define algunas constantes, como tamaños de tablas y banderas, que es usan 
en todo el sistema de archivos. MINIX ya tiene una historia. Una versión anterior tenía u sistema de 
archivos distinto, así que se proporciona apoyo tanto para el sistema de archivos viej( (VI) como para el 
actual (V2), en beneficio de los usuarios que deseen acceder a archiva escritos con la versión anterior. El 
superbioque de un sistema de archivos contiene un numen mágico que permite al sistema operativo 
identificar el tipo; las constantes SUPER MAGIC' y 
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SUPER V2 definen estos números. El apoyo de versiones antiguas no es algo que se mencione en los textos teóricos, 
pero siempre es importante para los implementadores de una versión nueva de cualquier software. Es preciso decidir 
cuánto esfuerzo se dedicará a facilitar la vida de los usuarios de la versión anterior. Veremos varios lugares del sistema 
de archivos en los que el apoyo de la versión antigua es importante. 

Type.h (línea 19600) define las estructuras de los nodos-i tanto viejos (VI) como nuevos (V2), tal como están 
organizados en el disco. El nodo-i V2 es dos veces más grande que el viejo, que se diseñó pensando en ahorrar espacio 
en sistemas sin disco duro y disquetes de 360 KB. La nueva versión cuenta con espacio para los tres campos de tiempo 
que los sistemas UNIX mantienen. En el nodo-i VI había sólo un campo de tiempo, pero un stat o un fstat lo 
"falsificaba" y devolvía una estructura stat que contenía los tres campos. Hay un problema menor para ofrecer apoyo a 
las dos versiones del sistema de archivos. El comentario de la línea 19616 subraya esto. El software minix viejo espera 
que el tipo gidt sea una cantidad de ocho bits, así que d2_gid debe declararse como de tipo ul6_t. 

Proto.h (línea 19700) proporciona prototipos de funciones en formas aceptables para los compiladores de C tanto 
antiguos (K&R) como nuevos (ANSÍ Standard). Se trata de un archivo largo, pero no muy interesante. Sin embargo, 
hay un punto que merece la pena destacar: en vista del gran número de llamadas al sistema distintas que maneja el 
sistema de archivos, y dada la forma como está organizado el sistema de archivos, las diversas funciones do xxx están 
dispersas en varios archivos. Proto.h está organizado por archivo y es una forma cómoda de encontrar el archivo que se 
debe consultar cuando se desea ver el código que maneja una llamada al sistema en particular. 

Por último, glo.h (línea 19900) define variables globales. Los buffers para los mensajes recibidos y de respuesta 
también están aquí. Se utiliza el truco que ya conocemos bien con la macro EXTERN, a fin de que todas las partes del 
sistema de archivos puedan acceder a estas variables. Al igual que en las demás partes de minix, el espacio de 
almacenamiento se reserva cuando se compila table.c. 

La parte de la tabla de procesos que corresponde al sistema de archivos está contenida en fproc.h (línea 20000). El 
arreglo fproc se declara con la macro EXTERN. Este arreglo contiene la máscara de modo, apuntadores a los nodos-i 
del directorio raíz y el directorio de trabajo actuales, el arreglo de descriptores de archivo, y el uid, gid y número de 
terminal de cada proceso. El identifícador del proceso y el del grupo de procesos también se encuentran aquí. Éstos se 
duplican en las partes de la tabla de procesos ubicada en el kemel y en el administrador de memoria. 

Se emplean varios campos para almacenar los parámetros de las llamadas al sistema que pueden quedar suspendidas 
a la mitad de su ejecución, como las lecturas de un conducto vacío. Los campos fpsuspended y jp revived en realidad 
sólo requieren un bit cada uno, pero casi todos los compiladores generan mejor código para caracteres que para campos 
de bits. También hay un campo para los bits FD CLOEXEC que exige el estándar POSix. Éstos sirven para indicar que 
se debe cerrar un archivo cuando se efectúa una llamada exec. 

Ahora llegamos a los archivos que definen otras tablas mantenidas por el sistema de archivos. El primero, buf.h 
(línea 20100), define el caché de bloques. Todas las estructuras de este archivo se declaran con EXTERN. El arreglo 
¿w/contiene todos los buffers, cada uno de los cuales comprende 
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una parte de datos, b, y un encabezado lleno de apuntadores, banderas y contadores. La parte de datos se declara como 
una unión de cinco tipos (línea 20117) porque a veces es aconsejable hacer referencia al bloque como un arreglo de 
caracteres, a veces como un directorio, etcétera. 

La forma correcta de hacer referencia a la parte de datos del buffer 3 como arreglo de caracteres es 

buf[3].b.b _ data porque buj\3}.b se refiere a la unión como un todo, de la cual se selecciona el campo b _ data. Aunque 

esta sintaxis es correcta, no es fácil de usar, así que en la línea 20142 se define una macro bdata que nos permite 

escribir buf[3].b_data en vez de buf[3].b.b _ data. Adviértase que b _ data (el campo de la unión) contiene dos 

caracteres de subrayado, en tanto que b data (la macro) sólo contiene uno, para distinguirlos. En las líneas 20143 a 
20148 se definen macros para otras formas de acceder al bloque. 

La tabla hash del buffer, bufhash, se define en la línea 20150. Cada entrada apunta a una lista de buffers. 
Originalmente todas las listas están vacías. Las macros al final de buf.h (líneas 20160 a 20166) definen diferentes tipos 
de bloques. Cuando se devuelve un bloque al caché de buffers después de usarse, se proporciona uno de estos valores 
para indicarle al administrador del caché si debe colocar el bloque al frente o al final de la lista LRU, y si debe 
escribirlo en disco inmediatamente o no. El bit WRITEIMMED indica que el bloque se debe reescribir de inmediato en 
disco si se modificó. El superbioque es la única estructura que se marca incondicionalmente así. ¿Qué hay con las 
demás estructuras que se marcan con MAYBE_WRITE_IMMED A Esto se define en include/minix/config.h como igual a 
WRITE IMMED si ROBUST es verdadero, o cero en caso contrario. En la configuración estándar de minix, ROBUST se 
define como cero, y estos bloques se escriben cuando se escriben bloques de datos. 

Por último, en la última línea (línea 20168) se define HASHMASK, con base en el valor de NR BUF HASH 
configurado en include/minix/config.h. Se hace un AND de HASH MASK con un número de bloque para determinar 
cuál entrada hashmask debe usarse como punto de partida cuando se busca un buffer de bloque. 

El siguiente archivo, dev.h (línea 20200), define la tabla dmap. La tabla en sí se declara en table.c con valores 
iniciales, así que esa versión no se puede incluir en varios archivos. Es por esto que se necesita dev.h. Dmap se declara 
aquí con extern, en lugar de EXTERN. La tabla permite transformar un número de dispositivo principal en el nombre de 
la tarea correspondiente. 

File.h (línea 20300) contiene la tabla intermedia filp (declarada como EXTERN) que sirve para contener la posición 
actual en el archivo y el apuntador al nodo-i (véase la Fig. 5-33), y que también indica si el archivo se abrió para 
lectura, escritura o ambas cosas, y cuántos descriptores de archivo están apuntando actualmente a la entrada. 

La tabla de candados de archivo, fi.leJ.ock (declarada como EXTERN), está en lock.h (línea 20400). El tamaño del 
arreglo lo determina NR LOCKS, que se define como 8 en const.h. Este número debe incrementarse si se desea 
implementar una base de datos multiusuario en un sistema minix. 

En inode.h (línea 20500) se declara la tabla de nodos-i inode (empleando EXTERN). Esta tabla también contiene 
los nodos-i que están en uso actualmente. Como ya dijimos, cuando se abre un archivo su nodo-i se trae a la memoria y 
se mantiene ahí hasta que se cierra el archivo. La definición de la estructura inode incluye información que se mantiene 
en la memoria pero que no se escribe en el nodo-i en disco. Cabe señalar que sólo hay una versión, y que nada es 
específico 
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para una versión dada aquí. Cuando se lee el nodo-i del disco, se resuelven las diferencias entre los sistemas de archivos 
VI y V2. El resto del sistema de archivos no necesita conocer el formato del FS en el disco, al menos en tanto llega el 
momento de reescribir información modificada. 

La mayor parte de los campos no deberán requerir explicación a estas alturas. No obstante, iseek merece algunos 
comentarios. Ya mencionamos que, como optimación, cuando el sistema de archivos se da cuenta de que un archivo se 
está leyendo secuencialmente trata de leer bloques y colocarlos en el caché antes de que sean solicitados. En el caso de 
archivos de acceso aleatorio no hay lectura adelantada. Cuando se efectúa una llamada lseek, se ajusta el campo i seek 
de modo que inhiba la lectura anticipada. 

El archivo param.h (línea 20600) es análogo al archivo del mismo nombre en el administrador de memoria; define 
nombres de campos de mensaje que contienen parámetros, de modo que el código pueda hacer referencia a, por 
ejemplo, bujfer, en lugar de m.ml_pl, que selecciona uno de los campos del buffer de mensaje m. 

En super.h (línea 20700) tenemos la declaración de la tabla de superbioques. Cuando se inicia el sistema, se carga 
aquí el superbioque del dispositivo raíz. A] montarse sistemas de archivos, sus superbioques también van aquí. Al igual 
que otras tablas, super block se declara como EXTERN. 

Asignación de espacio de almacenamiento del sistema de archivos 

El último archivo que veremos en esta sección no es un encabezado. Sin embargo, tal como hicimos al estudiar el 
administrador de memoria, parece apropiado examinar table.c inmediatamente después de describir los archivos de 
encabezado, ya que todos ellos se incluyen cuando se compila table.c. La mayor parte de las estructuras de datos que 
hemos mencionado —el caché de bloques, la tabla/?//?, etc.—, se definen con la macro EXTERN, lo mismo que las 
variables globales del sistema de archivos y la parte de la tabla de procesos que corresponde al FS. Tal como hemos 
visto en otras partes del sistema minix, el espacio de almacenamiento realmente se reserva cuando se compila table.c. 
Este archivo también contiene dos arreglos importantes inicializados. Call vector contiene el arreglo de apuntadores 
que se utiliza en el ciclo principal para determinar cuál procedimiento se encarga de cuál número de llamada al sistema. 
Vimos una tabla similar dentro del administrador de memoria. 

Algo que sí es nuevo es la tabla dmap de la línea 20914. Esta tabla tiene una fila para cada dispositivo principal, 
comenzando por el cero. Cuando se abre, cierra, lee o escribe un dispositivo, es esta tabla la que proporciona el nombre 
del procedimiento que se debe invocar para efectuar la operación. Todos estos procedimientos se encuentran en el 
espacio de direcciones del sistema de archivos. Muchos de ellos no hacen nada, pero algunos invocan una tarea para 
solicitar realmente E/S. La tabla también proporciona el número de tarea que corresponde a cada dispositivo principal. 

Siempre que se agrega un dispositivo principal a minix, se debe agregar una línea a esta tabla que indique cuál 
acción, en su caso, debe efectuarse cuando se abre, cierra, lee o escribe ese dispositivo. Como ejemplo sencillo, si se 
agrega una unidad de cinta a minix, cuando se abra su archivo especial el procedimiento de la tabla deberá verificar si la 
unidad de cinta está ya en uso o no. Para ahorrar a los usuarios el trabajo de modificar esta tabla durante una 
reconfiguración, se define una macro, DT, para automatizar el proceso (línea 20900). 
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Hay una línea en la tabla para cada dispositivo principal posible, y cada línea se escribe con la macro. Los 
dispositivos obligatorios tienen un 1 como valor del argumento enable de la macro. Algunas entradas no se usan, sea 
porque todavía no está listo un controlador proyectado o porque se eliminó un controlador viejo. Estas entradas se 
definen con un valor de O para enable. Las entradas para dispositivos que se pueden configurar en 
include/minix/config.h utilizan la macro habilitadora del dispositivo, por ejemplo, ENABLE WINI en la línea 20920. 

5.7.2 Administración de tablas 

Cada una de las tablas principales de bloques, nodos-i, superbioques, etc., tiene asociado un archivo que contiene 
procedimientos que manejan la tabla. El resto del sistema de archivos utiliza intensamente estos procedimientos, que 
constituyen la principal interfaz entre las tablas y el sistema de archivos. Por esta razón, resulta apropiado iniciar 
nuestro estudio del código del sistema de archivos con ellos. 


Administración de bloques 

El caché de bloques se administra con los procedimientos del archivo cache, c. Este archivo contiene los nueve 
procedimientos que se listan en la Fig. 5-34. El primero, getJblock (línea 21027) es la forma estándar en que el sistema 
de archivos obtiene bloques de datos. Cuando un procedimiento del sistema de archivos necesita leer un bloque de datos 
de usuario, un bloque de directorio, un superbioque o cualquier otro tipo de bloque, invoca getblock, especificando el 
dispositivo y el número de bloque. 


Procedimiento 

Función 

getblock 

Trae un bloque para leer o escribir 

putblock 

Devuelve un bloque solicitado con getblock 

alloczone 

Asigna una nueva zona (para alargar un archivo) 

freezone 

Libera una zona (cuando se elimina un archivo) 

rwblock 

Transfiere un bloque entre el disco y el caché 

invalídate 

Purga todos los bloques de caché de un dispositivo 

flushall 

Desaloja todos los bloques sucios de un dispositivo 

rwscattered 

Lee o escribe datos dispersos en un dispositivo 

rmlru 

Quita un bloque de su cadena LRU 


Figura 5-34. Procedimientos empleados para administrar bloques. 

Cuando se invoca get block, primero examina el caché de bloques para ver si el bloque solicitado está ahí. Si es así, 
get block devuelve un apuntador a él; si no, tiene que leer el bloque. Los bloques del caché se encadenan en 
NR BUF HASH listas enlazadas. NR BUF HASHes un parámetro afinable, junto con NR BUFS, el tamaño del caché 
de bloques. Ambos se establecen en inelude/ 
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minix/config.h. Al final de esta sección hablaremos un poco sobre cómo optimar el tamaño del caché de bloques y la 
tabla hash. La máscara HASHMASK es NRBUFHASH-l. Con 256 listas hash, la máscara es 255, así que todos los 
bloques de cada lista tienen números de bloque que terminan con la misma cadena de ocho bits, es decir, 00000000, 
00000001, ...,ollllllll. 

El primer paso suele ser examinar una cadena hash en busca de un bloque, aunque existe un caso especial, cuando 
se está leyendo un agujero en un archivo poco poblado, en el que se pasa por alto esta búsqueda. Ésta es la razón de la 
prueba de la línea 21055. En caso contrario, las dos líneas siguientes ajustan bp de modo que apunte al principio de la 
lista en la que estaría el bloque solicitado, si estuviera en el caché, aplicando HASH MASK al número de bloque. El 
ciclo de la siguiente línea examina esta lista para ver si se puede encontrar el bloque. Si el bloque se encuentra y no está 
en uso, se retira de la lista LRU; si ya está en uso, no estará en la lista LRÜ de todos modos. El apuntador al bloque 
encontrado se devuelve al invocador en la línea 21063. 

Si el bloque no está en la lista hash, no está en el caché, así que se toma el bloque menos recientemente utilizado de 
la lista LRU. El buffer escogido se retira de su cadena hash, ya que está a punto de adquirir un nuevo número de bloque 
y, por tanto, pertenece a una cadena hash distinta. Si el bloque está sucio, se reescribe en el disco en la línea 21095. Al 
hacerse esto con una llamada aflushall se reescriben todos los demás bloques sucios para el mismo dispositivo. Los 
bloques que actualmente están en uso nunca se escogen para ser desalojados, ya que no están en la cadena LRU. Sin 
embargo, casi nunca sucederá que los bloques estén en uso; normalmente, putblock libera los bloques inmediatamente 
después de usarlos. 

Tan pronto como está disponible el buffer, todos los campos, incluido bdev, se actualizan con los nuevos 
parámetros (líneas 21099 a 21104) y ya se puede traer el bloque del disco. No obstante, hay dos ocasiones en las que 
podría no ser necesario leer el bloque del disco. GetJblock se invoca con un parámetro onlysearch (sólo buscar). Esto 
puede indicar que se trata de una preobtención. Durante una preobtención se encuentra un bloque disponible, 
escribiendo el contenido anterior en el disco si es necesario, y se asigna un nuevo número de bloque al buffer, pero el 
campo b dev se ajusta aNO DEVpara indicar que todavía no hay datos válidos en este bloque. Veremos cómo se usa 
esto cuando estudiemos la función rwscattered. También puede usarse only search para indicar que el sistema de 
archivos necesita un bloque sólo para reescribirlo completo. En este caso, es un desperdicio leer primero la versión 
antigua. En cualquiera de estos dos casos se actualizan los parámetros, pero se omite la lectura en sí del disco (líneas 
21107 a 21111). Una vez que se lee el nuevo bloque, getJblock regresa a su invocador con un apuntador a dicho bloque. 

Supongamos que el sistema de archivos necesita un bloque de directorio temporalmente, a fin de buscar un nombre 
de archivo. El ES invoca getJblock para adquirir el bloque de directorio. Una vez que ha buscado el nombre en cuestión, 
el ES invoca putJblock (línea 21119) para devolver el bloque al caché, dejando el buffer disponible en caso de que se 
necesite después para un bloque distinto. 

Put block se encarga de colocar el bloque recién devuelto en la lista LRU y, en algunos casos, de reescribirlo en el 
disco. En la línea 21144 se toma la decisión de colocarlo al frente o al final de la lista LRU, dependiendo de block type, 
una bandera provista por el invocador que indica el tipo de bloque de que se trata. Los bloques que tal vez se 
necesitarán otra vez pronto se colocan al final, a fin de que permanezcan durante cierto tiempo en el caché. Los bloques 
con poca 
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probabilidad de necesitarse pronto otra vez se colocan al frente, donde se reutilizarán con rapidez. De momento, sólo los 
superbioques se tratan de esta manera. 

Una vez que el bloque se ha reubicado en la lista LRU, se efectúa otra prueba (líneas 21172 y 21173) para 
determinar si el bloque se debe reescribir en el disco inmediatamente. En la configuración estándar sólo los 
superbioques se marcan para escritura inmediata, pero la única ocasión en que se modifica un superbioque y es 
necesario escribirlo es cuando se redimensiona un disco en RAM durante la inicialización del sistema. En tal caso la 
escritura es en el disco en RAM, y es poco probable que el superbioque de un disco en RAM tenga que volver a leerse 
alguna vez. Por tanto, esta capacidad casi nunca se usa. Sin embargo, es posible editar la macro ROBUST en 
include/minix/config.h de modo que se marquen para escritura inmediata los nodos-i, bloques de directorio y otros 
bloques que son indispensables para el funcionamiento correcto del sistema de archivos mismo. 

Conforme un archivo crece, ocasionalmente es preciso asignar una nueva zona para contener los nuevos datos. El 
procedimiento allocz.one (línea 21180) se encarga de asignar zonas nuevas, cosa que hace encontrando una zona libre 
en el mapa de bits de zonas. No hay necesidad de buscar en el mapa de bits si ésta va a ser la primera zona de un 
archivo; se consulta el campo szsearch del superbioque, que siempre apunta a la primera zona disponible en el 
dispositivo. En los demás casos se intenta encontrar una zona cercana a la última zona existente del archivo actual, a fin 
de mantener juntas todas las zonas de un archivo. Esto se hace iniciando la exploración del mapa de bits en esta última 
zona (línea 21203). La transformación del número de bit del mapa de bits en el número de zona se efectúa en la línea 
21215, donde el bit 1 corresponde a la primera zona de datos. 

Cuando se elimina un archivo, sus zonas deben marcarse como desocupadas en el mapa de bits. Free z.one (línea 
21222) se encarga de devolver estas zonas; lo único que hace es invocar free_bit, pasándole el mapa de zonas y el 
número de bit como parámetros. Free bit también sirve para devolver nodos-i, pero sólo cuando se pasa el mapa de 
nodos-i como primer parámetro, naturalmente. 

La administración del caché requiere leer y escribir bloques. A fin de contar con una interfaz sencilla con el disco, 
se ha incluido el procedimiento rwJblock (línea 21243), que lee o escribe un bloque. De forma análoga, rwinode sirve 
para leer y escribir nodos-i. 

El siguiente procedimiento del archivo es invalídate (línea 21280). Este se invoca, por ejemplo, cuando se 
desmonta un disco, para retirar del caché todos los bloques pertenecientes al sistema de archivos que acaba de 
desmontarse. Si no se hiciera esto, cuando el dispositivo se volviera a utilizar (con un disquete distinto), el sistema de 
archivos podría encontrar los bloques antiguos en lugar de los nuevos. 

Flushall (línea 21295) es invocado por la llamada al sistema SYNC para escribir en disco todos los bloques sucios 
pertenecientes a un dispositivo dado. Este procedimiento se invoca una vez por cada dispositivo montado, y trata el 
caché de buffers como arreglo lineal, de modo que se encuentran todos los buffers sucios, incluso los que se están 
usando actualmente y no están en la lista LRU. Se examinan todos los buffers del caché, y los que pertenecen al 
dispositivo que se va a actualizar y necesitan escribirse se agregan a un arreglo de apuntadores llamado dirty. Este 
arreglo se declara como static para mantenerlo fuera de la pila, y posteriormente se pasa a rw scattered. 
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Rwscattered (línea 21313) recibe un identifícador de dispositivo, un apuntador a un arreglo de apuntadores a 
buífers, el tamaño del arreglo y una bandera que indica si se debe leer o escribir. Lo primero que hace este 
procedimiento es ordenar el arreglo que recibe por número de bloque, de modo que la operación de lectura o escritura se 
efectúe en un orden eficiente. Rw scattered se invoca con la bandera WRITING sólo desde la función flushall que 
acabamos de describir. En este caso el origen de estos números de bloque es fácil de entender: se trata de buffers que 
contienen datos de bloques que se leyeron antes y que se han modificado. La única llamada a rw scattered para una 
operación de lectura la efectúa rabead en read.c. Por ahora, sólo necesitamos saber que antes de la llamada a 
rw scattered se invocó repetidamente getJblock en modo de preobtención, reservando un grupo de buffers. Dichos 
buffers contienen números de bloque, pero ningún parámetro de dispositivo válido. Esto no es un problema, ya que 
rw scattered se invoca con un parámetro de dispositivo como uno de sus argumentos. 

Hay una diferencia importante en la forma como un controlador de dispositivo puede responder a una solicitud de 
lectura (en contraposición a una de escritura) hecha por rw scattered. Una solicitud de escritura de bloques se debe 
satisfacer plenamente, pero una solicitud de lectura de varios bloques puede ser manejada de diferente forma por los 
distintos controladores, dependiendo de lo que resulte más eficiente para el controlador en cuestión. Rabead a menudo 
invoca rw scattered solicitando una lista de bloques que podrían no necesitarse realmente, así que la mejor respuesta es 
obtener tantos bloques como puedan leerse fácilmente, pero no saltar desesperadamente de un lado a otro de un 
dispositivo que podría tener un tiempo de búsqueda sustancial. Por ejemplo, el controlador de disquete podría detenerse 
en una frontera de pista, y muchos otros controladores sólo leen bloques consecutivos. Una vez que se completa la 
lectura, rw scattered marca los bloques que se leyeron actualizando el campo de número de dispositivo de sus buffers 
de bloque. 

La última función de la Fig. 5-34 es rm.J.ru (línea 21387). Esta función, que sirve para quitar un bloque de la lista 
LRU, sólo es utilizada por getJblock en este archivo, así que se declara PRÍVATE en lugar de PUBLIC a fin de ocultarla 
de procedimientos externos al archivo. 

Antes de dejar el caché de bloques, diremos unas cuantas palabras acerca de su optimación. NRBUFHASH debe 
ser una potencia de 2; si es mayor que NRBUFS, la longitud media de la cadena hash será menor que 1. Si hay 
suficiente memoria para una gran cantidad de buffers, hay espacio para un gran número de cadenas hash, así que la 
decisión usual es hacer que NR BUF HASH sea la siguiente potencia de 2 mayor que NRJBUFS. El listado del texto 
muestra valores de 512 bloques y 1024 listas hash. El tamaño óptimo depende de la forma como se utilice el sistema, ya 
que eso determina cuántos bloques deben colocarse en buffers. Empíricamente, se determinó que un aumento del 
número de buffers más allá de 1024 no mejoraba el rendimiento al recompilarse el sistema minix, así que, al parecer, 
esta cantidad es suficiente para contener los binarios de todas las pasadas del compilador. Para otro tipo de trabajo 
podría ser adecuado un tamaño más pequeño, o podría ser que uno más grande mejorara el rendimiento. 

Los archivos binarios del sistema minix del CD-ROM se compilaron con un caché de bloques mucho más pequeño. 
Esto se debe a que se pretende que el binario de distribución se pueda ejecutar en el mayor número de máquinas 
posible. Se buscaba producir una versión de distribución de minix que se pudiera instalar en un sistema con sólo 2 MB 
de memoria RAM. Un sistema compilado con un caché de 1024 bloques requiere más de 2 MB de RAM. El binario que 
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distribuye también incluye todos los posibles controladores de disco duro y de otro tipo, que podrían ser inútiles en una 
instalación dada. La mayoría de los usuarios probablemente querrá editar include/minix/config.h y recompilar el sistema 
poco después de la instalación, excluyendo los controladores innecesarios y agrandando el caché de bloques hasta 
donde sea posible. 

Antes de dejar el tema del caché de bloques, mencionaremos que el límite de 64 KB para el tamaño de los 
segmentos de memoria en los procesadores Intel de 16 bits imposibilita el uso de un caché grande en esas máquinas. Es 
posible configurar el sistema de archivos de modo que utilice el disco en RAM como caché secundario para guardar los 
bloques que no quepan en el caché primario. No estudiaremos tal configuración aquí porque no es necesaria en un 
sistema Intel de 32 bits: siempre que sea factible, un caché primario grande ofrece el mejor rendimiento. No obstante, 
un caché secundario puede ser útil en una máquina (como una 286) que no tiene espacio para un caché primario grande 
dentro del espacio de direcciones virtual del sistema de archivos. Un caché secundario deberá tener un mejor 
rendimiento que un disco en RAM convencional. Un caché sólo contiene datos que se necesitan al menos una vez, y si 
tiene el tamaño suficiente puede mejorar mucho el rendimiento del sistema. No es posible definir anticipadamente "el 
tamaño suficiente"; sólo puede medirse determinando si un aumento adicional en el tamaño da pie a mejoras adicionales 
en el rendimiento. El comando time, que mide el tiempo empleado para ejecutar un programa, es una herramienta útil 
cuando se trata de optimar un sistema. 

Administración de nodos-i 

El caché de bloques no es la única tabla que necesita procedimientos de apoyo; la tabla de nodos-i también los necesita. 
Muchos de los procedimientos tienen una función similar a la que tienen los procedimientos de administración de 
bloques, y se listan en la Fig. 5-35. 


Procedimiento 

Función 

Get_inode 

Trae un nodo_i a la memoria 

Put_inode 

Devuelve un nodo_i que ya no se necesita 

Alloc_inode 

Asigna un nuevo nodo_i (para un archivo nuevo) 

Wipe_inode 

Despeja algunos campos de un nodo_i 

Free_inode 

Libera un nodo_i (cuando se borra un archivo) 

Update_times 

Actualiza campos de tiempo de un nodo_i 

Rw_inode 

Transfiere un nodo_i entre la memoria y el disco 

Oldicopy 

Convierte contenido de nodo_i para escribir en nodo_i VI 

New_icopy 

Convierte datos leídos de nodo_i de sistema de archivos V1 

Dup_inode 

Indica que alguien más está usando un nodo_i 


Figura 5-35. Procedimientos empleados para administrar nodos-i. 

El procedimiento getinode (línea 21534) es análogo a get block. Cuando una parte del sistema de archivos 
necesita un nodo-i, invoca get inode para adquirirlo. Lo primero que hace get inode 
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es examinar la tabla inode para ver si el nodo-i ya está presente. Si es así, getinode incrementa el contador de usos y 
devuelve un apuntador al nodo. Esta búsqueda está contenida en las líneas 21546 a 21556. Si el nodo-i no está presente 
en la memoria, se carga invocando rwinode. 

Una vez que el procedimiento que requería el nodo-i termina de usarlo, el nodo se devuelve invocando el 
procedimiento put inode (línea 21578), que decrementa el contador de usos icount. Si esta cuenta llega a cero, quiere 
decir que el archivo ya no se está usando y es posible quitar el nodo-i de la tabla. Si el nodo está sucio, se reescribe en el 
disco. 

Si el campo i link es cero, ninguna entrada de directorio está apuntando al archivo, así que pueden liberarse todas 
sus zonas. Cabe señalar que la llegada a cero de la cuenta de usos y del número de enlaces son dos sucesos distintos, 
con diferentes causas y diferentes consecuencias. Si el nodo-i es para un conducto, es preciso liberar todas las zonas, 
aunque el número de enlaces no sea cero. Esto sucede cuando un proceso que lee de un conducto libera el conducto. No 
tiene sentido tener un conducto para un solo proceso. 

Cuando se crea un archivo nuevo, se debe asignar un nodo-i con alloc inode (línea 21605). minix permite montar 
dispositivos en modo de sólo lectura, así que se examina el superbioque para comprobar que se pueda escribir en el 
dispositivo. A diferencia de las zonas, donde se intenta mantener cercanas las zonas de un archivo, cualquier nodo-i es 
igualmente bueno. A fin de ahorrarse el tiempo que tomaría una búsqueda en el mapa de bits de nodos-i, se aprovecha el 
campo del superbioque en el que se registra el primer nodo-i desocupado. 

Una vez adquirido el nodo-i, se invoca get inode para colocar el nodo-i en la tabla que está en la memoria. A 
continuación se inicializan sus campos, una parte en línea (líneas 21641 a 21648) y una parte usando el procedimiento 
wipe mode (línea 21664). Se escogió esta división del trabajo en particular porque wipe inode también se necesita en 
otros puntos del sistema de archivos para despejar ciertos campos de un nodo-i (pero no todos). 

Cuando se elimina un archivo, su nodo-i se libera invocando free inode (línea 21684). Lo único que sucede aquí es 
que el bit correspondiente del mapa de bits de nodos-i se pone en O y se actualiza el campo del superbioque donde se 
registra el primer nodo-i desocupado. 

La siguiente función, update times (línea 21704), se invoca para obtener el tiempo del reloj del sistema y modificar 
los campos de tiempo que requieran una actualización. Las llamadas al sistema stat y fstat también invocan 
update times, así que ésta se declara PUBLIC. 

El procedimiento rw inode (línea 21731) es análogo a rwJblock. Su trabajo consiste en traer un nodo-i del disco, 
cosa que se lleva a cabo ejecutando estos pasos: 

1. Calcular qué bloque contiene el nodo-i requerido. 

2. Leer el bloque invocando getblock. 

3. Extraer el nodo-i y copiarlo en la tabla inode. 

4. Devolver el bloque invocando putJblock. 

Rw inode es un poco más complejo que lo que indica esta descripción básica, así que se necesitan algunas 
funciones adicionales. Primero, dado lo costoso que resulta obtener el tiempo actual, si se requiere modificar los 
campos de tiempo del nodo-i lo único que se hace es indicarlo 
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encendiendo bits del campo iupdate del nodo-i mientras éste está en la memoria. Si este campo es distinto de cero 
cuando se hace necesario escribir el nodo-i, se invoca updatetimes para actualizar los tiempos. 

Segundo, la historia de minix agrega una complicación: en la versión antigua (VI) del sistema de archivos los 
nodos-i en el disco tienen una estructura diferente que en V2. Dos funciones, oldicopy (línea 21774) y newJ.copy 
(línea 21821) se encargan de las conversiones. La primera efectúa la conversión entre la información de nodo-i que está 
en la memoria y el formato empleado por el sistema de archivos VI. La segunda efectúa la misma conversión para los 
discos del sistema de archivos V2. Ambas funciones se invocan sólo desde este archivo, así que se declaran PRÍVATE. 
Cada función realiza conversiones en ambas direcciones (disco a memoria o memoria a disco), minix se ha 
implementado en sistemas que usan un orden de byte diferente del de los procesadores Intel. Toda implementación 
emplea el orden de byte nativo en su disco; el campo sp->native del superbioque identifica el orden empleado. Tanto 
old icopy como newJ.copy invocan las funciones convl y conv4 para intercambiar el orden de los bytes si es necesario. 

El procedimiento dup inode (línea 21865) se limita a incrementar la cuenta de usos del nodo-i; 
se invoca cuando un archivo abierto se abre otra vez. La segunda vez que se abre el archivo, no hace falta traer otra vez 
el nodo-i del disco. 

Administración de superbioques 

El archivo supere contiene procedimientos que administran el superbioque y los mapas de bits. Hay cinco 
procedimientos en el archivo, los cuales se listan en la Fig. 5-36. 


Procedimiento 

Función 

allocbit 

Asigna un bit del mapa de zonas o nodos-i 

freebit 

Libera un bit del mapa de zonas o nodos-i 

getsuper 

Busca un dispositivo en la tabla de superbioques 

mounted 

Informa si un nodo-i está en un FS montado (o raíz) 

readsuper 

Lee un superbioque 


Figura 5-36. Procedimientos empleados para administrar el superbioque y los mapas de bits. 

Cuando se necesita un nodo-i o una zona, se invoca alloc inode o alhc zone, como ya vimos. Estas dos funciones 
invocan allocJbit (línea 21926) para realizar la búsqueda real en el mapa de bits pertinente. La búsqueda implica tres 
ciclos anidados, a saber: 

1. El exterior recorre todos los bloques de un mapa de bits. 

2. El de en medio recorre todas las palabras de un bloque. 

3. El interior recorre todos los bits de una palabra. 

El ciclo de en medio compara la palabra con el complemento a uno de cero, esto es, una palabra completa llena de 
unos. Si la comparación es verdadera, es que no hay nodos-i o zonas libres, y se prueba la siguiente palabra. Cuando se 
encuentra una palabra con un valor distinto, 
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esto implica que debe tener por lo menos un bit O, así que se ingresa en el ciclo interior para encontrar el bit libre (es 
decir, 0). Si ya se examinaron todos los bloques sin éxito, quiere decir que no hay nodos-i o zonas libres, y se devuelve 
el código NO BIT (0). Las búsquedas como ésta pueden consumir una cantidad considerable de tiempo de procesador, 
pero el empleo de los campos del superbioque que apuntan al primer nodo-i desocupado y la primera zona libre, mis¬ 
mos que se pasan a allocbit en origin, ayuda a acortar dichas búsquedas. 




La liberación de un bit es más sencilla que la asignación de un bit, ya que no es necesario buscar. Free-bit (línea 
22003) calcula cuál bloque del mapa de bits contiene el bit que se debe liberar y pone en cero el bit correcto invocando 
getblock, poniendo en cero el bit en la memoria, e invocando putJblock. 

El siguiente procedimiento, getsuper (línea 22047), sirve para buscar un dispositivo específico en la tabla de 
superbioques. Por ejemplo, cuando se va a montar un sistema de archivos es necesario comprobar que no esté montado 
ya. Esta verificación puede efectuarse pidiendo a get super que encuentre el dispositivo del sistema de archivos. Si no 
se encuentra el dispositivo, es que el sistema de archivos no está montado. 

La siguiente función, mounted (línea 22067), sólo se invoca cuando se cierra un dispositivo por bloques. 
Normalmente, todos los datos de un dispositivo que están en caché se desechan cuando el dispositivo se cierra por 
última vez. Sin embargo, si el dispositivo está montado, esto no es aconsejable. Mounted se invoca con un apuntador al 
nodo-i de un dispositivo, y simplemente devuelve TRUE si el dispositivo es el dispositivo raíz o es un dispositivo 
montado. 

Por último, tenemos readsuper (línea 22088). Esta función es en parte análoga a rwJblock y rw inode, pero sólo 
se invoca para leer. Durante el funcionamiento normal del sistema no es necesario escribir superbioques. Read super 
verifica la versión del sistema de archivos del cual acaba de leerse y efectúa conversiones, si es necesario, a fin de que 
la copia del superbioque que está en la memoria tenga la estructura estándar aunque se haya leído de un disco con una 
estructura de superbioque distinta. 

Administración de descriptores de archivo 

minix contiene procedimientos especiales para administrar descriptores de archivo y la tabla filp (véase la Fig. 5-33), y 
están contenidos en el archivo filedes.c. Cuando se crea o abre un archivo, se requieren un descriptor de archivo libre y 
una ranura de filp desocupada. El procedimiento get Jd (línea 22216) sirve para encontrarlos. Sin embargo, ni el 
descriptor ni la ranura se marcan como "en uso", porque se deben efectuar muchas verificaciones antes de que se sepa a 
ciencia cierta que la llamada creat u open va a tener éxito. 

GetJilp (línea 22263) sirve para ver si un descriptor de archivo está dentro del intervalo; si es así, se devuelve su 
apuntador filp. 

El último procedimiento de este archivo esfind Jilp (línea 22277), que se necesita para averiguar si un proceso está 
escribiendo en un conducto roto (es decir, un conducto que ningún otro proceso ha abierto para lectura). FindJilp 
localiza los lectores potenciales mediante una búsqueda de fuerza bruta de la tabla filp. Si no se puede encontrar un 
lector, es que el conducto está roto y la escritura fracasa. 
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Candados de archivos 

Las funciones de candados de registros de POSix se muestran en la Fig. 5-37. Se puede poner un candado a una parte de 
un archivo para lectura y escritura, o sólo para escritura, con una llamada fcntl que especifique una solicitud FSETLK 
o FSETLKW. Podemos determinar si existe un candado para una parte de un archivo empleando la solicitud 
FGETLK 


Operación 

Significado 

FSETLK 

Asegura la región para lectura y escritura 

FSETLKW 

Asegura la región para escritura 

FGETLK 

Informa si la región está asegurada 


Figura 5-37. Las operaciones de candados de registro consultivos de posix. Estas operaciones se solicitan con la llamada al 
sistema fcntl. 

Sólo hay dos funciones en el archivo lock.c. Lockop (línea 22319) es invocada por la llamada al sistema fcntl 
con un código para una de las operaciones que se muestran en la Fig. 5-37. Lock op realiza ciertas verificaciones de 
error para asegurarse de que la región especificada sea válida. Cuando se está poniendo un candado, no debe haber 
conflicto con otro candado ya existente, y cuando se está quitando un candado no se debe partir a la mitad otro candado 
existente. Para quitar cualquier candado se invoca la otra función de este archivo, lockrevive (línea 22463), la cual 
despierta todos los procesos que están bloqueados esperando candados. Esta estrategia es un término medio; se 
requeriría código adicional para determinar exactamente cuáles procesos están esperando que se quite un candado en 
particular. Los procesos que todavía están esperando un archivo asegurado se bloquearán otra vez cuando se inicien. 
Este procedimiento se basa en el supuesto de que los candados no se usarán con mucha frecuencia. Si se fuera a 
construir una base de datos multiusuario de gran tamaño en un sistema minix, podría ser aconsejable reimplementar 
esto. 

También se invoca lock revive cuando se cierra un archivo que tiene un candado, cosa que podría ocurrir, por 
ejemplo, si un proceso se termina antes de que termine de usar un archivo asegurado. 

5.7.3 El programa principal 

El ciclo principal del sistema de archivos está contenido en el archivo main.c, a partir de la línea 22537. 
Estructuralmente, este ciclo es muy parecido al ciclo principal del administrador de memoria y de las tareas de E/S. La 
llamada a get work espera que llegue el siguiente mensaje de solicitud (a menos que ahora pueda atenderse un proceso 
que estaba suspendido en un conducto o terminal). También se establece una variable global, who, con el número de 
ranura del proceso invocador en la tabla de procesos, y otra variable global, fs call, con el número de la llamada al 
sistema que se va a ejecutar. 

Ya de vuelta en el ciclo principal, se establecen tres banderas: fp apunta a la ranura del invocador en la tabla de 
procesos, superuser indica si el invocador es el superusuario o no, y 
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dontreply se inicializa en FALSE. Luego viene la atracción principal: la llamada al procedimiento que lleva a cabo la 
llamada al sistema. El procedimiento por invocar se selecciona usando fscall como índice del arreglo de apuntadores a 
procedimientos, callvector. 

Una vez que el control regresa al ciclo principa], si dont reply está encendida, se inhibe la respuesta (p. ej., un 
proceso se bloqueó tratando de leer de un conducto vacío). En caso contrario, se envía una respuesta. La instrucción 
final del ciclo principal se diseñó de modo que detectara si un archivo se está leyendo secuencialmente y cargara el 
siguiente bloque en el caché antes de que se solicite, a fin de mejorar el rendimiento. 

El procedimiento get work (línea 22572) verifica si se ha revivido algún proceso que antes estaba bloqueado. De 
ser así, éstos tienen prioridad sobre los mensajes nuevos. Sólo si no hay trabajo interno pendiente el sistema de archivos 
llama al kemel para obtener un mensaje, en la línea 22598. 

Después de completarse la llamada al sistema, con éxito o no, se envía una respuesta al invocador con reply (línea 
22608). El proceso podría haber sido terminado por una señal, así que se hace caso omiso del código de situación 
devuelto por el kemel. De todos modos, en un caso así nada se podría hacer. 

Funciones de inicialización 

El resto de main.c consiste en funciones que se usan sólo cuando se inicia el sistema. Antes de que el sistema de 
archivos ingrese en su ciclo principal, se inicializa invocando fsinit (línea 22625), que a su vez invoca varias otras 
funciones para inicializar el caché de bloques, obtener los parámetros de arranque, cargar el disco en RAM si es 
necesario y cargar el superbioque del dispositivo raíz. El siguiente paso es inicializar la parte de la tabla de procesos que 
corresponde al sistema de archivos para todas las tareas y servidores, hasta init (líneas 22643 a 22654). Por último, se 
prueban varias constantes importantes, para ver si tienen sentido, y se envía un mensaje a la tarea de memoria con la 
dirección de la parte de la tabla de procesos que corresponde al sistema de archivos; el programa ps usa esta dirección. 

La primera función que fs init invoca es buf_pool (línea 22679), que construye las listas enlazadas utilizadas por el 
caché de bloques. En la Fig. 5-31 se muestra el estado normal del caché de bloques, en el que todos los bloques están 
enlazados tanto en la cadena LRU como en una cadena hash. Puede ser útil ver la forma en que se da la situación de la 
Fig. 5-31. Inmediatamente después de que buf_pool inicializa el caché, todos los buffers están en la cadena LRU, y 
todos están enlazados en la cadena hash cero, como en la Fig. 5-38(a). Cuando se solicita un buffer, y mientras está en 
uso, tenemos la situación de la Fig. 5-38(b), donde vemos que se ha quitado un bloque de la cadena LRU y ahora está 
en una cadena hash distinta. Normalmente, los bloques se liberan y devuelven a la cadena LRU de inmediato. En la Fig. 
5-38(c) se muestra la situación después de que el bloque se ha devuelto a la cadena LRU. Aunque este bloque ya no está 
en uso, se puede acceder a él otra vez para usar los mismos datos, si es necesario, así que se mantiene en la cadena hash. 
Después de que el sistema ha estado funcionando durante algún tiempo, es de esperar que se habrán usado casi todos los 
bloques y estarán distribuidos aleatoriamente entre las diferentes cadenas hash. En ese momento la cadena LRU se vena 
como en la Fig. 5-31. 
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Frente 


Final 


OCZJ- 




k □—*-NULL 
n □—*-NULL 

(a) 


Frente Final 



(b) 


Final Frente 



Figura 5-38. Inicialización del caché de bloques, (a) Antes de usarse buffers. (b) Después 
de solicitarse un bloque, (c) Después de liberarse el bloque. 

La siguiente función es get boot_parameters (línea 22706), que envía un mensaje a la tarea del 
sistema pidiéndole una copia de los parámetros de arranque. La siguiente función, loadram (línea 
22722), que asigna espacio para un disco en RAM, necesita esos parámetros. Si los parámetros de 
arranque especifican 

rootdev =ram 

el sistema de archivos del dispositivo raíz se copia del dispositivo nombrado por ramimagedev al 
disco en RAM bloque por bloque, comenzando por el bloque de arranque, sin interpretación de las 
diversas estructuras de datos del sistema de archivos. Si el parámetro de arranque ramsize es menor 
que el tamaño del sistema de archivos del dispositivo raíz, se hará que el disco en RAM 
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tenga el tamaño suficiente para contenerlo. Si ramsize especifica un tamaño mayor que el del sistema de archivos del 
dispositivo raíz, se asigna el tamaño especificado y el sistema de archivos del disco en RAM se ajusta de modo que 
utilice todo el espacio especificado (líneas 22819 a 22825). La llamada &put_block de la línea 22825 es el único caso 
en el que el sistema de archivos escribe un superbioque. 

Load ram asigna espacio para un disco en RAM vacío si se especifica un ramsize distinto de cero. En este caso, ya 
que no se copian estructuras de sistema de archivos, no será posible utilizar el dispositivo en RAM como sistema de 
archivos en tanto no se inicialice con el comando mkfs. Como alternativa, semejante disco en RAM podría utilizarse 
como caché secundario si en la compilación del sistema de archivos se incluye el apoyo correspondiente. 

La última función de main.c es load super (línea 22832), que inicializa la tabla de superbioques y trae a la 
memoria el superbioque del dispositivo raíz. 

5.7.4 Operaciones con archivos individuales 

En esta sección estudiaremos una por una las llamadas al sistema que operan con archivos individuales (en 
contraposición a, digamos, operaciones con directorios). Comenzaremos con la creación, apertura y cierre de archivos, 
y luego examinaremos con cierto detalle el mecanismo de lectura y escritura de archivos. Después, veremos la forma en 
que los conductos y sus operaciones difieren de las operaciones con archivos. 

Cómo crear, abrir y cerrar archivos 

El archivo open.c contiene el código para seis llamadas al sistema: creat, open, mknod, mkdir, close y lseek. 
Examinaremos creat y open juntas, y luego veremos las demás. 

En versiones antiguas de UNIX, las llamadas creat y open tenían distinto propósito. Tratar de abrir un archivo que 
no existía era un error, y los archivos nuevos tenían que crearse con creat, que también podía servir para truncar un 
archivo existente a longitud cero. Sin embargo, en los sistemas POSix ya no es necesario tener dos llamadas al sistema 
distintas. En POSix, la llamada open ahora permite crear un archivo nuevo o truncar un archivo viejo, así que la llamada 
CREAT ahora representa un subconjunto de los posibles usos de la llamada open y en realidad sólo es necesaria por 
razones de compatibilidad con programas viejos. Los procedimientos que manejan creat y open son do creat (línea 
22937) y do open (línea 22951). (Al igual que en el administrador de memoria, en el sistema de archivos se usa la 
convención de que la llamada al sistema xxx se lleva a cabo con el procedimiento do xxx.) La apertura o creación de un 
archivo implica tres pasos: 

1. Encontrar el nodo-i (asignarlo e inicializarlo si el archivo es nuevo). 

2. Encontrar o crear la entrada de directorio. 

3. Preparar y devolver un descriptor de archivo para el archivo. 

Tanto creat como open hacen dos cosas: obtienen el nombre de un archivo y luego invocan common open que se 
ocupa de las tareas comunes a ambas llamadas. 
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Lo primero que hace commonopen (línea 22975) es asegurarse de que estén disponibles un descriptor de archivo y 
una ranura de tabla filp libres. Si la función invocadora especificó la creación de un archivo nuevo (llamando con el bit 
OCREAT encendido), se invoca newnode en la línea 22998. Newnode devuelve un apuntador a un nodo-i existente si 
la entrada de directorio ya existe; si no, crea tanto una entrada de directorio nueva como un nodo-i. Si no es posible 
crear el nodo-i, new node establece la variable global err code. Un código de error no siempre implica un error. Si 
new node encuentra un archivo existente, el código de error devuelto indicará que el archivo existe, pero en este caso 
ese error es aceptable (línea 23001). Si el bit O CREAT no está encendido, se busca el nodo-i empleando un método 
alternativo, la función eat_path de path.c, que comentaremos más adelante. En este punto, lo que debemos entender es 
que si no se encuentra un nodo-i o no se logra crear, common open terminará con un error antes de llegar a la línea 
23010. En los demás casos, la ejecución continuará aquí con la asignación de un descriptor de archivo y la ocupación de 
una ranura de la tabla/?//?. Después de esto, si se acaba de crear un archivo nuevo, se pasan por alto las líneas 23017 a 
23094. 

Si el archivo no es nuevo, el sistema de archivos debe determinar de qué tipo de archivo se trata, qué modo tiene, 
etc., para ver si lo puede abrir. La llamada aforbidden en la línea 23018 realiza primero una inspección general de los 
bits rwx. Si el archivo es del tipo normal y common open se invocó con el bit 0 TRUNC encendido, el archivo se trunca 
a longitud cero y se invoca forbidden otea vez (línea 23024), en esta ocasión para asegurarse de que se puede escribir el 
archivo. Si los permisos así lo indican, se invocan wipe inode y rw inode para reinicializar el nodo-i y escribirlo en el 
disco. Otros tipos de archivos (directorios, archivos especiales y conductos con nombre) se someten a pruebas 
apropiadas. En el caso de un dispositivo, en la línea 23053 se efectúa una llamada (empleando la estructura dmap) a la 
rutina apropiada para abrir el dispositivo. En el caso de un conducto con nombre, se invoca pipe open (línea 23060) y 
se realizan varias pruebas pertinentes para los conductos. 

El código de common _ open, lo mismo que muchos otros procedimientos del sistema de archivos, contiene una 

gran cantidad de instrucciones que buscan detectar diversos errores y combinaciones no permitidas. Si bien no es muy 
elegante, este código es indispensable para tener un sistema dé archivos robusto, libre de errores. Si algo anda mal, el 
descriptor de archivo y la ranura/;'//? que se habían asignado se desocupan, y se libera el nodo-i (líneas 23098 a 23101). 
En este caso el valor devuelto por common open será un número negativo, para indicar un error. Si no hay problemas se 
devuelve el descriptor de archivo, un valor positivo. 

Éste es un buen sitio para analizar con mayor detalle el funcionamiento de new node (línea 23111), que se encarga 
de la asignación del nodo-i y de la introducción del nombre de ruta en el sistema de archivos para las llamadas creat y 
open. Las llamadas mknod y mkdir, que todavía no estudiamos, también usan este procedimiento. La instrucción de la 
línea 23128 analiza sintácticamente el nombre de ruta (es decir, lo examina componente por componente) hasta llegar al 
directorio final; la llamada a advance fres líneas más adelante trata de averiguar si el componente final se puede abrir. 

Por ejemplo, en la llamada 


fd = creat(7usr/ast/foobar", 0755); 
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lastdir trata de cargar el nodo-i parsi/usr/ast en las tablas y devolverle un apuntador. Si el archivo no existe, 
necesitaremos este nodo-i en breve para agregar foobar al directorio. Todas las demás llamadas al sistema que agregan 
o eliminan archivos utilizan también last dir para abrir primero el último directorio de la ruta. 

Si newnode descubre que el archivo no existe, invoca alloc inode en la línea 23134 para asignar y cargar un nodo- 
i nuevo, devolviéndole un apuntador. Si no quedan nodos-i libres, newnode falla y devuelve NILINODE. 

Si es posible asignar un nodo-i, la operación continúa en la línea 23144, donde se llenan algunos de los campos, se 
escribe el nodo-i de vuelta en el disco y se introduce el nombre de archivo en el directorio final (en la línea 23149). Una 
vez más vemos que el sistema de archivos debe verificar constantemente la presencia de errores y, si encuentra uno, 
debe liberar cuidadosamente todos los recursos, como nodos-i y bloques, que tiene en su poder. Si estuviéramos dis¬ 
puestos a dejar simplemente que minix entrara en un pánico cuando se agotaran, digamos, los nodos-i, en lugar de 
anular todos los efectos de la llamada actual y devolver un código de error al invocador, el sistema de archivos sería 
mucho más sencillo. 

Como ya se mencionó, los conductos requieren un tratamiento especial. Si no hay por lo menos un par lector/escritor 
para un conducto, pipeopen (línea 23176) suspende el invocador; 

en caso contrario, invoca reléase, que examina la tabla de procesos en busca de procesos que están bloqueados 
esperando el conducto. Si se encuentra alguno, se le revive. 

La llamada mknod se maneja con dojnknod (línea 23205). Este procedimiento es similar a do creat, excepto que 
sólo crea el nodo-i y una entrada de directorio para él. De hecho, la mayor parte del trabajo corre por cuenta de la 
llamada a new node en la línea 23217. Si el nodo-i ya existe, se devuelve un código de error. Este es el mismo código 
que era un resultado aceptable de new node cuando commonopen lo invocaba; en este caso, empero, el código de error 
se devuelve al invocador, que es de suponer actuará de manera acorde. No necesitamos efectuar aquí el análisis caso por 
caso que hicimos cuando describimos common open. 

La llamada mkdir se maneja con la función domkdir (línea 23226). Al igual que en las otras llamadas al sistema 
que hemos estudiado aquí, new node desempeña un papel importante. Los directorios, a diferencia de los archivos, 
siempre tienen enlaces y nunca están completamente vacíos porque todo directorio debe contener dos entradas desde el 
momento de su creación: las entradas y que se refieren al directorio mismo y a su directorio padre. Existe un 
límite para el número de enlaces que un archivo puede tener: LINK MAX (definido en include/limits.h como 127 para el 
sistema minix estándar). Puesto que la referencia al directorio padre en un hijo es un enlace con el padre, lo primero que 
do mkdir hace es ver si es posible crear otro enlace en el directorio padre (línea 23240). Una vez que se pasa esta 
prueba, se invoca new node. Si new node tiene éxito, se crean las entradas de directorio para y (líneas 23261 y 
23262). Todo esto es sencillo, pero podría haber fallas (por ejemplo, si el disco está lleno), y para evitar un embrollo se 
toman providencias para anular las etapas iniciales del proceso si no es posible completarlo. 

Cerrar un archivo es más fácil que abrirlo. El trabajo corre por cuenta de do close (línea 23286). Los conductos y 
archivos especiales requieren algo de atención, pero en el caso de los archivos normales casi lo único que hay que hacer 
es decrementar el contador filp y verificar si es cero, en cuyo caso se devolverá el nodo-i con putJinode. El paso final 
consiste en quitar 
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cyalesquier candados y revivir cualquier proceso que haya estado suspendido esperando que se quitara un candado del 
archivo. 

Cabe señalar que la devolución de un nodo-i implica que su contador en la tabla inode se decrementa, a fin de 
poder quitarlo de la tabla posteriormente. Esta operación nada tiene que ver con la liberación del nodo-i (es decir, 
ajustar un bit en el mapa de bits para indicar que ya está disponible). El nodo-i sólo se libera cuando el archivo se 
elimina de todos los directorios. 

El procedimiento final de open.c es do lseek (línea 23367). Cuando se efectúa una búsqueda en un archivo, se 
invoca este procedimiento para asignar un nuevo valor a la posición en el archivo. En la línea 23394 se inhibe la lectura 
adelantada; un intento explícito de colocarse en una posición determinada en un archivo es incompatible con el acceso 
secuencial. 


Lectura de un archivo 

Una vez que se ha abierto un archivo, se puede leer o escribir. Se emplean muchas funciones durante la lectura y la 
escritura, y están contenidas en el archivo read.c. Explicaremos éstas primero y luego pasaremos al siguiente archivo, 
write.c, para examinar el código que se emplea específicamente en la escritura. Hay varias diferencias entre la lectura y 
la escritura, pero también suficientes similitudes como para que lo único que do read (línea 23434) tenga que hacer sea 
invocar el procedimiento común readwrite con una bandera puesta en READING. Veremos en la siguiente sección que 
dowrite es igual de sencilla. 

Read write se inicia en la línea 23443. Hay cierto código especial en las líneas 23459 a 23462 que el administrador 
de memoria utiliza para hacer que el sistema de archivos cargue para él segmentos enteros en el espacio de usuario. Las 
llamadas normales se procesan a partir de la línea 23464. Luego se efectúan algunas verificaciones de validez (p. ej., 
leer de un archivo que se abrió sólo para escritura) y se inicializan algunas variables. Las lecturas de archivos especiales 
por caracteres no pasan por el caché de bloques, así que se excluyen en la línea 23498. 

Las pruebas de las líneas 23507 a 23518 sólo aplican a las escrituras y tienen que ver con archivos que podrían 
crecer a más de la capacidad del dispositivo, o escrituras que van a cerrar un agujero en el archivo al escribir más allá 
del fin del archivo. Como vimos cuando hablamos de las generalidades de minix, la presencia de múltiples bloques por 
zona causa problemas que se deben resolver explícitamente. Los conductos también son especiales y se verifica si se 
bata de un conducto. 

El corazón del mecanismo de lectura, al menos en el caso de los archivos ordinarios, es el ciclo que comienza en la 
línea 23530. Este ciclo divide la solicitud en trozos, cada uno de los cuales cabe en un solo bloque de disco. Un trozo 
principia en la posición actual y se extiende hasta que se satisface una de las siguientes condiciones: 

1. Ya se leyeron todos los bytes. 

2. Se llegó a una frontera de bloque. 

3. Se llegó al fin del archivo. 
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Estas reglas implican que un trozo nunca requiere dos bloques de disco para ser satisfecho. En la Fig. 5-39 se muestran 
tres ejemplos de cómo se determina el tamaño de trozo, para tamaños de trozo de 6, 2 y 1 bytes, respectivamente. El 
cálculo en sí se efectúa en las líneas 23632 a 23641. 


Número de byte 

01 23456789 10 

I-1-1-1-1-1-1-1-1-1-1“ 

L_Bloque-- 



Posición actual = 6 -n 

iiiiii mt/A n 


Posición actual = 9 


I I I I I I TT 


Eb 


11 12 13 

H-1-h 

— Bloque — 


Trozo = 6 


Trozo = 2 


Trozo = 1 


14 

H- 


15 16 


Figura 5-39. Tres ejemplos de cómo se determina el primer tamaño de trozo para un archivo 
de 10 bytes. El tamaño de bloque es de 8 bytes, y el número de bytes solicitados es 6. El trozo 
se muestra sombreado. 


La lectura real del trozo corre por cuenta de rwchunk. Cuando el control regresa, se incrementan varios contadores 
y apuntadores y se inicia la siguiente iteración. Cuando el ciclo termina, es posible que se actualicen la posición en el 
archivo y otras variables (p. ej., apuntadores de conductos). 

Por último, si procede la lectura anticipada, el nodo-i del cual se va a leer y la posición en la cual se va a comenzar a 
leer se almacenan en variables globales para que, una vez que se haya enviado el mensaje de respuesta al usuario, el 
sistema de archivos pueda ponerse a trabajar en la obtención del siguiente bloque. En muchos casos el sistema de 
archivos se bloquea esperando el siguiente bloque de disco, y durante ese tiempo el proceso de usuario puede trabajar 
con los datos que ya recibió. Esta organización traslapa el procesamiento y la E/S y puede mejorar el rendimiento 
sustancialmente. 

El procedimiento rw chunk (línea 23613) se ocupa de tomar un nodo-i y una posición en el archivo, convertirlos en 
un número de bloque de disco físico, y solicitar la transferencia de ese bloque (o una porción de él) al espacio de 
usuario. La transformación de la posición relativa dentro del archivo en la dirección física de disco corre por cuenta de 
read map, que tiene conocimiento de los nodos-i y los bloques de indirección. En el caso de un archivo ordinario, las 
variables b y dev de las líneas 23637 y 23638 contienen el número de bloque físico y el número de dispositivo, 
respectivamente. La llamada a getblock de la línea 23660 es donde se pide al manejador del caché que encuentre el 
bloque y lo lea si es necesario. 
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Una vez que se tiene un apuntador al bloque, la llamada a syscopy de la línea 23670 se ocupa de transferir la 
porción requerida de él al espacio de usuario. A continuación se libera el bloque con putJblock, de modo que pueda ser 
desalojado del caché posteriormente, cuando llegue el momento. (Después de ser adquirido por getblock, el bloque no 
estará en la cola LRU y no se devolverá a dicha cola en tanto el contador del encabezado del bloque indique que está en 
uso, así que no será susceptible de desalojo; putJblock decrementa el contador y devuelve el bloque a la cola LRU 
cuando el contador llega a cero.) El código de la línea 23680 indica si una operación de escritura llenó el bloque. Sin 
embargo, el valor que se pasa a putblock en n no afecta la forma como el bloque se coloca en la cola; todos los bloques 
se colocan ahora al final de la cadena LRU. 

Read map (línea 23689) convierte una posición lógica en el archivo en un número de bloque físico inspeccionando 
el nodo-i. Si los bloques están lo bastante cerca del principio del archivo como para quedar dentro de una de las 
primeras siete zonas (las que están ahí mismo en el nodo-i), basta un cálculo sencillo para determinar qué zona se 
necesita, y luego qué bloque. En el caso de archivos más adelante en el archivo, podría ser necesario leer uno o más 
bloques de indirección. 

Se invoca rd indir (línea 23753) para leer un bloque de indirección. Existe un procedimiento aparte para hacer esto 
porque los datos pueden tener diferentes formatos en el disco, dependiendo de la versión del sistema de archivos y del 
hardware en el que se haya escrito el sistema de archivos. Las conversiones se efectúan aquí, si es necesario, para que el 
resto del sistema de archivos vea los datos en una sola forma. 

Readahead (línea 23786) convierte la posición lógica en un número de bloque físico, invoca get block para 
asegurarse de que el bloque esté en el caché (o se coloque en él) y luego devuelve el bloque inmediatamente. Después 
de todo, read ahead no puede hacer nada con el bloque; sólo trata de mejorar la probabilidad de que el bloque esté en el 
caché si se utiliza pronto. 

Cabe señalar que read ahead sólo se invoca desde el ciclo principal de main; no se invoca como parte del 
procesamiento de la llamada al sistema read. Es importante darse cuenta de que la llamada a read ahead se efectúa 
después de haberse enviado la respuesta, con objeto de que el usuario pueda seguir ejecutándose incluso si el sistema de 
archivos tiene que esperar un bloque de disco mientras lee anticipadamente. 

Read ahead en sí está diseñado para pedir un solo bloque; invoca a la última función de read.c, rabead, para 
efectuar realmente el trabajo. Rabead (línea 23805) funciona según la teoría de que si un poco más es bueno, mucho 
más es mejor. Puesto que los discos y otros dispositivos de almacenamiento tardan un tiempo relativamente largo en 
localizar el primer bloque solicitado pero después pueden leer con relativa rapidez varios bloques adyacentes, podría ser 
posible tener muchos más bloques leídos con muy poco esfuerzo adicional. Se presenta una solicitud de preobtención a 
getJblock, que prepara el caché de bloques para recibir varios bloques juntos. Luego se invoca rwscattered con una 
lista de bloques. Ya explicamos esto antes; recuérdese que cuando rw scattered invoca realmente los controladores de 
dispositivos, cada uno está en libertad de satisfacer sólo la parte de la solicitud que puede manejar con eficiencia. Todo 
esto suena muy complicado, pero las complicaciones hacen posible una agilización significativa de las aplicaciones que 
leen grandes cantidades de datos de disco. 

En la Fig. 5-40 se muestran las relaciones entre algunos de los principales procedimientos que intervienen en la 
lectura de un archivo; en particular, quién invoca a quién. 
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Puntos de entrada 



Figura 5-40. Algunos de los procedimientos que intervienen en la lectura de un archivo. 


Escritura de un archivo 

El código para escribir en archivos está en write.c. La escritura de un archivo es similar a su lectura, y do_\vrite (línea 
24025) simplemente invoca read write con la bandera WRITING. Una diferencia importante entre la lectura y la 
escritura es que esta última requiere la asignación de nuevos bloques de disco. Writemap (línea 24036) es análoga a 
read map, sólo que en lugar de buscar números de bloques físicos en el nodo-i y en sus bloques de indirección, 
introduce números nuevos ahí (para ser precisos, introduce números de zona, no de bloque). 

El código de write map es largo y detallado porque debe manejar varios casos. Si la zona por insertar está cerca del 
principio del archivo, simplemente se inserta en el nodo-i (línea 24058). 

El peor caso es cuando un archivo excede el tamaño que se puede manejar con un bloque de indirección sencilla, y 
se requiere un bloque de doble indirección. A continuación, será necesario asignar un bloque de indirección sencilla y 
colocar su dirección en el bloque de doble indirección. Al igual que en la lectura, se invoca un procedimiento aparte, 
wrindir. Si el bloque de doble 
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indirección se adquiere correctamente, pero el disco está lleno y no es posible asignar el bloque de indirección sencilla, 
se deberá devolver el bloque doble para evitar corromper el mapa de bits. 

Una vez más, si simplemente pudiéramos tirar la toalla y abandonamos al pánico en este punto, el código sería 
mucho más sencillo. Sin embargo, desde el punto de vista del usuario es mucho más agradable que el agotamiento de 
espacio en disco simplemente devuelva un error de write, en lugar de causar una caída del computador con un sistema 


(a) 

(b) 

(c) 

(d) 

(e) 

(f) 


[~24~| Zonas libres: 12 20 31 36... 

I 24 | 25 | 


[ 24 | 25 | 40~| 

1 24 | 25 | 40 | 41 | 

1 24 | 25 | 40 | 41 1 62 | 

| 24 1 25 | 40 | 41 | 62 1 63| 


— Número de bloque 


Figura 5-41. (a) - (f) La asignación sucesiva de bloques de 1K con una zona de 2K. 
de archivos inconsistente. 

Wr indir (línea 24127) invoca una de las rutinas de conversión, conv2 o conv4, para realizar las conversiones de 
datos necesarias, y coloca un nuevo número de zona en un bloque de indirección. Tenga presente que el nombre de esta 
función, al igual que muchas otras funciones que tienen que ver con lectura y escritura, no es literalmente correcto. La 
escritura real en el disco corre por cuenta de las funciones que mantienen el caché de bloques. 

El siguiente procedimiento de write.c es clear z.one (línea 24149), que se ocupa del problema de borrar bloques 
que repentinamente están en medio de un archivo. Esto sucede cuando se efectúa una búsqueda más allá del final de un 
archivo, seguida de la escritura de datos nuevos. Por fortuna, esta situación no ocurre con demasiada frecuencia. 

Newblock (línea 24190) es invocada por rw chunk cada vez que se necesita un nuevo bloque. En la Fig. 5-41 se 
muestran seis etapas sucesivas del crecimiento de un archivo secuencial. El tamaño de bloque es de 1K y el de zona es 
de 2K en este ejemplo. 


La primera vez que se invoca new block, asigna la zona 12 (bloques 24 y 25). En la siguiente ocasión, newJblock 
usa el bloque 25, que ya se asignó pero todavía no está en uso. En la tercera llamada se asigna la zona 20 (bloques 40 y 
41), y así sucesivamente. ZeroJblock (línea 24243) despeja un bloque, borrando su contenido anterior. Esta descripción 
es mucho más larga que el código en sí. 

Conductos 

Los conductos son similares a los archivos ordinarios en muchos sentidos. En esta sección nos concentraremos en las 
diferencias. Todo el código que describiremos está en pipe.c. 
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En primer lugar, los conductos se crean de forma diferente, con la llamada pipe, no con creat. La llamada PIPE se 
ejecuta con do_pipe (línea 24332). Lo único que do_pipe hace realmente es asignar un nodo-i para el conducto y 
devolver dos descriptores de archivo para él. Los conductos son propiedad del sistema, no del usuario, y se encuentran 
en el dispositivo de conductos designado (configurado en include/minix/config.h), que bien podría ser un disco en 
RAM, ya que los datos de los conductos no se tienen que conservar permanentemente. 

La lectura y escritura de un conducto es un poco diferente de la lectura y escritura de un archivo, porque un 
conducto tiene capacidad finita. Un intento de escritura en un conducto que ya está lleno causa la suspensión del 
escritor. Asimismo, la lectura de un conducto vacío suspende al lector. Efectivamente, un conducto tiene dos 
apuntadores, la posición actual (utilizada por los lectores) y el tamaño (utilizado por los escritores), para determinar de 
dónde vienen o adonde van los datos. 

Pipecheck (línea 24385) efectúa las diversas pruebas para comprobar si una operación con un conducto es posible. 
Además de las pruebas mencionadas, que pueden dar pie a la suspensión del invocador, pipe check invoca reléase para 
ver si un proceso que antes se había suspendido por falta o exceso de datos ya puede revivirse. Estas reactivaciones se 
realizan en la línea 24413 y en la línea 24452, para escritores y lectores dormidos, respectivamente. También se detecta 
aquí la escritura en un conducto roto (sin lectores). 

El acto de suspender un proceso corre por cuenta de suspend (línea 24463). Lo único que hace esta función es 
guardar los parámetros de la llamada en la tabla de procesos y poner la bandera dont reply en TRUE para inhibir el 
mensaje de respuesta del sistema de archivos. 

El procedimiento reléase (línea 24490) se invoca para ver si un proceso que estaba suspendido esperando un 
conjunto ya puede continuar. Si reléase encuentra uno, invoca revive para izar una bandera y que el ciclo principal se 
fije en él después. Esta función no es una llamada al sistema, pero se lista en la Fig. 5-27(c) porque usa el mecanismo de 
transferencia de mensajes. 

El último procedimiento de pipe, c es doJunpause (línea 24560). Cuando el administrador de memoria está tratando 
de enviar una señal a un proceso, debe averiguar si ese proceso está suspendido esperando un conducto o un archivo 
especial (en cuyo caso deberá despertársele con un error EINTR). Puesto que el administrador de memoria nada sabe 
acerca de los conductos ni de los archivos especiales, envía un mensaje al sistema de archivos para preguntarle. Ese 
mensaje es procesado por dounpause, que revive el proceso si está bloqueado. Al igual que revive, dounpause tiene 
cierto parecido con las llamadas al sistema, aunque no es una. 

5.7.5 Directorios y rutas 

Ya terminamos de ver cómo se leen y escriben archivos. Nuestra siguiente tarea es ver cómo se manejan los nombres de 
ruta y los directorios. 

Conversión de una ruta en un nodo-i 

Muchas llamadas al sistema (p. ej., open, unlink y mount) tienen nombres de ruta (es decir, nombres de archivo) 
como parámetros. En su mayor parte, estas llamadas deben obtener el nodo-i del 
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archivo nombrado antes de que puedan ponerse a trabajar en la llamada misma. La forma en que un nombre de ruta se 
convierte en un nodo-i es un tema que ahora vamos a examinar con detalle. Ya vimos un bosquejo general en la Fig. 5- 
14. 

El análisis sintáctico de los nombres de ruta se efectúa en el archivo path.c. El primer procedimiento, eat_path 
(línea 24727), acepta un apuntador a un nombre de ruta, lo analiza, hace que su nodo-i se cargue en la memoria y 
devuelve un apuntador al nodo-i. Eat_path efectúa su trabajo invocando lastdir para obtener el nodo-i del último 
directorio e invocando después advance para obtener el componente final de la ruta. Si la búsqueda fracasa, por ejemplo 
porque uno de los directorios de la ruta no existe, o existe pero está protegido contra búsquedas, se devuelve 
NIL INODE en lugar de un apuntador al nodo-i. 

Los nombres de ruta pueden ser absolutos o relativos y pueden tener una cantidad arbitraria de componentes, separados 
por diagonales. Last dir (línea 24754) se ocupa de estas cuestiones; 

comienza (línea 24771) por examinar el primer carácter del nombre de ruta para ver si se trata de una ruta absoluta o 
relativa. Si la ruta es absoluta, se ajusta rip de modo que apunte al nodo-i raíz; 
si es relativa, se hace que rip apunte al nodo-i del directorio de trabajo actual. 

En este punto, last dir tiene el nombre de ruta y un apuntador al nodo-i del directorio en el que debe buscar el 
primer componente. Ahora la función ingresa en un ciclo en la línea 24782 para analizar sintácticamente el nombre de 
ruta, componente por componente. Cuando last dir llega al final, devuelve un apuntador al último directorio. 

Get name (línea 24813) es un procedimiento de utilería que extrae componentes de cadenas. Más interesante es 
advance (línea 24855), que recibe como parámetros un apuntador a un directorio y una cadena, y busca la cadena en el 
directorio. Si encuentra la cadena, advance devuelve un apuntador a su nodo-i. Los detalles de la transferencia de un 
sistema de archivos montado en otro se manejan aquí. 

Aunque advance controla la búsqueda de la cadena, el cotejo en sí de la cadena contra las entradas de directorio se 
efectúa en searchdir (línea 24936), que es el único lugar del sistema de archivos en el que se examinan realmente 
archivos de directorio. Este procedimiento contiene dos ciclos anidados, uno para iterar sobre los bloques de un 
directorio y otro para iterar sobre las entradas de un bloque. También se usa search dir para introducir nombres en 
directorios y borrarlos de ellos. En la Fig. 4-52 se muestran las relaciones entre algunos de los procedimientos más 
importantes que se emplean en la búsqueda de nombres de ruta. 


Montado de sistemas de archivos 

Dos llamadas al sistema que afectan el sistema de archivos globalmente son mount y umount, las cuales permiten 
"pegar" sistemas de archivos independientes situados en dispositivos secundarios distintos para formar un solo árbol de 
nombres sin fronteras. El montado, como vimos en la Fig. 5-32, se logra efectivamente leyendo el nodo-i raíz y el 
superbioque del sistema de archivos que se va a montar y estableciendo dos apuntadores en su superbioque. Uno de 
ellos apunta al nodo-i en el que se va a montar, y el otro apunta al nodo-i raíz del sistema de archivos montado. Estos 
apuntadores "enganchan" los dos sistemas de archivos. 
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El establecimiento de estos apuntadores se efectúa en el archivo mount.c mediante do mount en las líneas 25231 y 
25232. Las dos páginas de código que preceden al establecimiento de los apuntadores se ocupan casi exclusivamente de 
verificar todos los errores que pueden ocurrir mientras se monta un sistema de archivos. Entre ellos están: 

1. El archivo especial dado no es un dispositivo por bloques. 

2. El archivo especial dado es un dispositivo por bloques pero ya está montado. 

3. El sistema de archivos por montar tiene un número mágico corrompido. 

4. El sistema de archivos por montar no es válido (p. ej., no tiene nodos-i). 

5. El archivo en el que se va a montar no existe o es un archivo especial. 

6. No hay espacio para los mapas de bits del sistema de archivos montado. 

7. No hay espacio para el superbioque del sistema de archivos montado. 

8. No hay espacio para el nodo-i raíz del sistema de archivos montado. 

Tal vez parezca inapropiado seguir insistiendo en este punto, pero la realidad de cualquier sistema operativo es que una 
fracción sustancial del código se dedica a realizar tareas menores que no son muy estimulantes intelectualmente pero 
que son cruciales para que el sistema se pueda usar. Si un usuario intenta montar el disco flexible equivocado por 
accidente, digamos, una vez al mes, y esto conduce a una caída y a un sistema de archivos inconsistente, el usuario 
pensará que el sistema no es confiable y culpará al diseñador, no a sí mismo. 

Thomas Edison hizo alguna vez una observación que es pertinente aquí. Dijo que el "genio" es 1% inspiración y 
99% transpiración. La diferencia entre un sistema bueno y uno mediocre no es lo brillante del algoritmo de 
planificación del primero, sino su atención a los detalles. 
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Desmontar un sistema de archivos es más fácil que montarlo, pues hay menos cosas que pueden salir mal. 
Dounmount (línea 25241) se encarga de esto. La única cuestión importante aquí es asegurarse de que ningún proceso 
tenga archivos abiertos o directorios de trabajo en el sistema que se va a quitar. Esta verificación es directa: basta con 
examinar toda la tabla de nodos-i para ver si algún nodo que está en memoria pertenece al sistema de archivos que se va 
a desmontar (aparte del nodo-i raíz). Si lo hay, la llamada umount falla. 

El último procedimiento de mount.c es name to dev (línea 25299), que toma el nombre de ruta de un archivo 
especial, obtiene su nodo-i y extrae sus números de dispositivo principal y secundario. Éstos se almacenan en el nodo-i 
mismo, en el lugar donde normalmente iría la primera zona. Esta ranura está disponible porque los archivos especiales 
no tienen zonas. 

Enlazamiento y desenlazamiento de archivos 

El siguiente archivo por considerar es link.c, que se ocupa de enlazar y desenlazar archivos. El procedimiento dolink 
(línea 25434) es muy parecido a do mount en cuanto a que casi todo el código se ocupa de la verificación de errores. 
Algunos de los errores que pueden ocurrir en la llamada 

link(tile_name, link_name); 

se listan a continuación: 

1. Nombre archivo no existe o no es posible acceder a él. 

2. Nombre archivo ya tiene el número máximo de enlaces. 

3. Nombre archivo es un directorio (sólo el superusuario puede crear enlaces a él). 

4. Nombre ertlace ya existe. 

5. Nombrearchivo y nombre ertlace están en dispositivos distintos. 

Si no hay errores, se crea una nueva entrada de directorio con la cadena nombre enlace y el número de nodo-i de 
nombre archivo. En el código, namel corresponde a nombre archivo y name2 corresponde a nombre enlace. 
Search dir crea la entrada real al ser invocado desde do link en la línea 25485. 

Los archivos y directorios se eliminan desenlazándolos. Dounlink (línea 25504) realiza el trabajo de las dos 
llamadas al sistema unlink y rmdir. Una vez más, es preciso efectuar varias verificaciones; la prueba de que un 
archivo existe y de que un directorio no es un punto de montaje son realizadas por el código común de do unlink, y 
luego se invoca ya sea remove dir (quitar directorio) o unlinkJile (desenlazar archivo), dependiendo de la llamada al 
sistema que se esté manejando. Hablaremos de estas funciones en breve. 

La otra llamada al sistema que se maneja en link.c es rename (cambiar de nombre). Los usuarios de UNIX están 
familiarizados con el comando de shell mv que en última instancia utiliza esta llamada; su nombre refleja otro aspecto 
de la llamada, rename no sólo puede cambiar el 
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nombre de un archivo dentro de un directorio, también puede transferir efectivamente un archivo de un directorio a otro, 
y hacer esto atómicamente, lo que evita ciertas condiciones de competencia. El trabajo corre por cuenta de dorename 
(línea 25563). Hay muchas condiciones que deben probarse antes de que se pueda llevar a cabo este comando. Entre 
ellas están: 

1. El archivo original debe existir (línea 25578). 

2. El nombre de ruta antiguo no debe ser un directorio que esté arriba del nuevo nombre de ruta en el árbol de 

directorios (líneas 25596 a 25613). 

3. Ni. ni., son aceptables como nombres viejo o nuevo (líneas 25618 y 25619). 

4. Ambos directorios padre deben estar en el mismo dispositivo (línea 25622). 

5. En ambos directorios padre debe poderse escribir y efectuar búsquedas, y deben estar en un dispositivo en el 

que se pueda escribir (líneas 25625 y 25626). 

6. Ni el nombre antiguo ni el nuevo pueden ser de un directorio que tenga un sistema de archivos montado en él. 

Hay algunas otras condiciones que deben verificarse si el nombre nuevo ya existe; la más importante es que sea posible 
eliminar el archivo existente que tiene el mismo nombre. 

En el código para do rename hay unos cuantos ejemplos de decisiones de diseño que se tomaron para minimizar la 
posibilidad de ciertos problemas. El cambio de nombre de un archivo para darle un nombre que ya existe podría fallar 
en un disco lleno, aunque en última instancia no se utilice espacio adicional. Para que esto suceda tendría que eliminarse 
el archivo viejo primero, y esto es lo que se hace en las líneas 25660 a 25666. La misma lógica se emplea en la línea 
25680, eliminando el nombre de archivo viejo antes de crear un nombre nuevo en el mismo directorio, a fin de evitar la 
posibilidad de que el directorio necesite adquirir un bloque adicional. Sin embargo, si el archivo nuevo y el viejo van a 
estar en diferentes directorios, no surge ese problema, y en la línea 25685 se crea un nuevo nombre de archivo (en un 
directorio distinto) antes de eliminar el viejo, porque desde el punto de vista de la integridad del sistema una caída que 
dejara dos nombres de archivo apuntando al mismo nodo-i sería mucho menos grave que una caída que dejara un nodo-i 
al que no apunta ninguna entrada de directorio. La probabilidad de quedarse sin espacio durante una operación de 
cambio de nombre es baja, y la de una caída del sistema todavía más baja, pero en estos casos nada cuesta estar 
preparados para lo peor. 

Las funciones restantes de link.c apoyan las que ya hemos estudiado. Además, la primera de ellas, trúncate (línea 
25717) se invoca desde varios otros puntos del sistema de archivos. Esta función recorre un nodo-i zona por zona, 
liberando todas las zonas que encuentra, así como todos los bloques de indirección. Removedir (línea 25777) realiza 
varias pruebas adicionales para asegurarse de que el directorio se puede eliminar, y luego invoca unlinkJile (línea 
25818). Si no se encuentran errores, la entrada de directorio se borra y la cuenta de enlaces en el nodo-i se reduce en 


uno. 
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5.7.6 Otras llamadas al sistema 

El último grupo de llamadas al sistema es un surtido de actividades que tienen que ver con estado, directorios, 
protección, tiempo y otros servicios. 

Modificación de directorios y de la situación de archivos 

El archivo stadir.c contiene el código para cuatro llamadas al sistema: chdir, chroot, stat y pstat. Al estudiar 
lastdir vimos cómo la primera acción en una búsqueda de ruta es examinar el primer carácter de la ruta, para 
determinar si es una diagonal o no. Dependiendo del resultado, se establece un apuntador al directorio raíz o al 
directorio de trabajo. 

Cambiar de un directorio de trabajo (o raíz) a otro sólo es cuestión de modificar estos dos apuntadores dentro de la 
tabla de procesos del invocador. Estos cambios se efectúan con dochdir (línea 25924) y do chroot (línea 25963). Las 
dos funciones realizan las verificaciones necesarias y luego invocan chango (línea 25978) para abrir el nuevo directorio 
y reemplazar el viejo. 

En do chdir el código de las líneas 25935 a 25951 no se ejecuta en las llamadas chdir hechas por procesos de 
usuario; es sólo para las llamadas efectuadas por el administrador de memoria cuando desea cambiar al directorio de un 
usuario con el fin de manejar llamadas exec. Cuando un usuario trata de ejecutar un archivo, digamos a.out en su 
directorio de trabajo, es más fácil para el administrador de memoria cambiar a ese directorio que tratar de averiguar 
dónde está. 

Las otras dos llamadas al sistema que se manejan en este archivo, stat y fstat, son básicamente iguales, excepto 
por la forma como se especifica el archivo. La primera da un nombre de ruta, en tanto que la segunda proporciona el 
descriptor de archivo de un archivo abierto. Los dos procedimientos de nivel más alto, dostat (línea 26014) y do Jstat 
(línea 26035), invocan statinode para que efectúe el trabajo. Antes de llamar a statinode, do stat abre el archivo para 
obtener su nodo-i. De esta forma, tanto do stat como do Jstat pasan un apuntador a un nodo-i a stat inode. 

Todo lo que stat inode (línea 26051) hace es extraer información del nodo-i y copiarla en un buffer. El buffer se 
debe copiar explícitamente en el espacio de usuario invocando syscopy en la línea 26088 porque es demasiado grande 
para caber en un mensaje. 

Protección 

El mecanismo de protección de minix emplea los bits rwx. Hay tres juegos de bits para cada archivo: para el propietario, 
para su grupo y para otros. Los bits se establecen con la llamada al sistema chmod, que se efectúa con do chmod en el 
archivo protec.c (línea 26124). Después de efectuar una serie de verificaciones de validez, el modo se cambia en la 
línea 26150. 

La llamada al sistema CHOWN es similar a chmod en cuanto a que ambas modifican un campo de nodo-i intemo en 
algún archivo. La implementación también es similar, aunque do chown (línea 26163) sólo puede ser utilizada por el 
superusuario para cambiar el propietario. Los usuarios ordinarios pueden emplear esta llamada para cambiar el grupo de 
sus propios archivos. 

La llamada al sistema umask permite al usuario establecer una máscara (almacenada en la tabla de procesos) que 
excluye ciertos bits en las llamadas al sistema creat subsecuentes. La 
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implementación completa sería una sola instrucción, la línea 26209, si no fuera porque la llamada debe devolver el 
valor antiguo de la máscara como resultado. Esta carga adicional triplica el número de líneas de código necesarias 
(líneas 26208 a 26210). 

La llamada al sistema ACCESS permite a un proceso averiguar si puede acceder a un archivo de cierta forma (p. 
ej., para leerlo), y se implementa con do access (línea 26217), que obtiene el nodo-i del archivo e invoca el 
procedimiento interno forbidden (línea 26242) para ver si el acceso está prohibido. Forbidden examina el uid y el gid, 
así como la información del nodo-i. Dependiendo de lo que encuentra, la función escoge uno de los tres grupos rwx y 
verifica si el acceso está permitido o prohibido. 

Read only (línea 26304) es un pequeño procedimiento interno que indica si el sistema de archivos en el que está 
situado el nodo-i que es su parámetro está montado sólo para lectura o para lectura y escritura. Este procedimiento es 
necesario para evitar la escritura en sistemas de archivos que se montaron sólo para lectura. 

Tiempo 

minix cuenta con varias llamadas al sistema que tienen que ver con el tiempo: utime, time, stime y times. Éstas se 
resumen en la Fig. 5-43. Aunque la mayor parte de ellas no tienen nada que ver con archivos, tiene sentido incluirlas en 
el sistema de archivos porque en el nodo-i de un archivo se guarda información de tiempos. 


Llamada 

Función 

UTIME 

Fija el tiempo de última modificación de un archivo 

TIME 

Fija el tiempo real actual en segundos 

STIME 

Establece el reloj de tiempo real 

TIMES 

Obtiene los tiempos de contabilidad de los procesos 


Figura 5-43. Las cuatro llamadas al sistema relacionadas con el tiempo. 

Cada archivo tiene asociados tres números de 32 bits. Dos de éstos registran los tiempos de última modificación y 
de último acceso de un archivo. El tercero indica cuándo fue modificado por última vez el estado del nodo-i mismo. 
Este tiempo cambia en casi todos los accesos a un archivo, excepto si es con read o con exec. Estos tiempos se 
mantienen en el nodo-i. Con la llamada al sistema utime, el propietario del archivo o el superusuario pueden establecer 
los tiempos de acceso y de modificación. El procedimiento do utime (línea 26422) del archivo time, c implementa la 
llamada al sistema obteniendo el nodo-i y almacenando el tiempo en él. En la línea 26450 se restablecen las banderas 
que indican que se requiere una actualización del tiempo, a fin de que el sistema no efectúe una costosa y redundante 
llamada a clock time. 

El sistema de archivos no mantiene el tiempo real; esto lo hace la tarea del reloj dentro del kemel. Por tanto, la 
única forma de obtener o establecer el tiempo real es enviar un mensaje a la 
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tarea del reloj. Esto es, de hecho, lo que do time y dostime hacen. El tiempo real está en segundos a partir del lo. de 
enero de 1970. 

El kemel mantiene también la información de contabilidad. En cada tic del reloj, el kemel carga un tic a algún 
proceso. Esta información puede obtenerse enviando un mensaje a la tarea del sistema, y esto es lo que hace do Jims 
(línea 26492). El procedimiento no se llama do times porque la mayor parte de los compiladores de C anteponen un 
carácter de subrayado a todos los símbolos externos, y la mayor parte de los enlazadores trunca los símbolos a ocho 
caracteres. Esto haría imposible distinguir entre do time y do times. 

Lo que falta 

El archivo misc.c contiene procedimientos para unas cuantas llamadas al sistema que no embonan en otras áreas. La 
llamada al sistema dup duplica un descriptor de archivo; en oteas palabras, crea un nuevo descriptor de archivo que 
apunta al mismo archivo que su argumento. La llamada tiene una variante DUP2. Ambas versiones de la llamada se 
implementan con do dup (línea 26632). Esta función se incluye en minix como apoyo para programas binarios viejos. 
Ambas llamadas son obsoletas. La versión actual de la biblioteca C de minix invoca la llamada fcntl cuando encuentra 
cualquiera de ellas en un archivo fuente en C. 


Operación 

Significado 

FDUPFD 

Duplica un descriptor de archivo 

FGETFD 

Obtiene la bandera de cerrar-al-ejecutar 

FSETFD 

Establece la bandera de cerrar-al-ejecutar 

FGETFL 

Obtiene banderas de estado de archivo 

FSETFL 

Establece banderas de estado de archivo 

FGETLK 

Obtiene estado de candados de un archivo 

FSETLK 

Pone candado de lectura/escritura a un archivo 

FSETLKW 

Pone candado de escritura a un archivo 


Figura 5-44. Los parámetros de solicitud de posix para la llamada al sistema fcntl. 

fcntl, que se maneja con do Jcntl (línea 26670) es la forma preferida de solicitar operaciones con un archivo 
abierto. Los servicios se solicitan empleando las banderas definidas por POSIX que se describen en la Fig. 5-44. La 
llamada se invoca con un descriptor de archivo, un código de solicitud y argumentos adicionales según sea necesario 
para la solicitud específica. Por ejemplo, el equivalente de la antigua llamada 

dup2(fd, fd2); 

sería fcntl(fd, FJ3UPFD, fd2); 
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Varias de estas solicitudes establecen o leen una bandera; el código tiene sólo unas cuantas líneas. Por ejemplo, la 
solicitud FSETFD enciende un bit que obliga a cerrar un archivo cuando su propietario emite un exec. La solicitud 
fjgetfd sirve para determinar si un archivo deberá cerrarse o no cuando se haga una llamada exec. Las solicitudes 
FJ5ETFL y fjgetfl permiten izar banderas para indicar que un archivo dado está disponible en modo no bloqueador o 






para operaciones de anexión. 

DoJ'cntl también maneja el empleo de candados de archivos. Una llamada que especifica el comando F GETLK, 
F SETLK o F SETLKW se traduce a una llamada a lock op, que ya vimos en una sección anterior. 

La siguiente llamada al sistema es SYNC, que copia en el disco todos los bloques y nodos-i que han sido 
modificados desde que se cargaron. La llamada se procesa con do sync (línea 26730), que simplemente examina todas 
las tablas en busca de entradas sucias. Los nodos-i deben procesarse primero, ya que rwJinode deja sus resultados en el 
caché de bloques. Una vez que se han escrito todos los nodos-i sucios en el caché de bloques, todos los bloques sucios 
se escriben en el disco. 

Las llamadas al sistema fork, exec, exit y SET son en realidad llamadas del administrador de memoria, pero sus 
resultados deben registrarse aquí también. Cuando un proceso bifurca, es imprescindible que el kemel, el administrador 
de memoria y el sistema de archivos se enteren de ello. Estas "llamadas al sistema" no provienen de procesos de 
usuario, sino del administrador de memoria. Do Jork, doexit y do set registran la información pertinente en la parte de 
la tabla de procesos que corresponde al sistema de archivos. Doexec busca y cierra (con do closé) todos los archivos 
que se marcaron para cerrarse al ejecutar. 

La última función de este archivo no es en realidad una llamada al sistema, pero se maneja como tal. Se trata de 
dorevive (línea 26921), que se invoca cuando una tarea que antes no había podido completar un trabajo solicitado por 
el sistema de archivos, como suministrar datos de entrada a un proceso de usuario, ya ha completado dicho trabajo. A 
continuación el sistema de archivos revive el proceso y le envía el mensaje de respuesta. 


5.7.7 La interfaz con dispositivos de E/S 

La E/S en minix se efectúa enviando mensajes a tareas que están dentro del kemel. La interfaz del sistema de archivos 
con dichas tareas está contenida en el archivo device.c. Cuando se requiere E/S real con un dispositivo, se invoca dev io 
(línea 27033) desde read write para manejar archivos especiales por caracteres, y desde rwJblock en el caso de 
archivos especiales por bloques. Dev io construye un mensaje estándar (Fig. 3-15) y lo envía a la tarea especificada. 
Las tareas se invocan con la línea 

(*dmap[major].dmpa_rw)(task, &dev_mess); 

(línea 27056). Esto llama las funciones a través de apuntadores contenidos en el arreglo dmap que se define en 
table.c. Todas las funciones que se ocupan de esto están aquí en device.c. Mientras dev io espera una respuesta de la 
tarea, el sistema de archivos espera; no tiene multiprogra-mación interna. Sin embargo, tales esperas suelen ser cortas 
(p. ej., 50 ms). 
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Es posible que los archivos especiales requieran un procesamiento especial cuando se abran o cierren. Lo que deba 
hacerse exactamente dependerá del tipo de dispositivo. La tabla dmap también se usa para determinar qué funciones se 
invocan para abrir y cerrar cada tipo de dispositivo principal. El procedimiento devopcl (línea 27071) se llama para los 
dispositivos de disco, sean disquetes, discos duros o dispositivos basados en memoria. La línea 

mess_ptr->PROC_NR = fp - fproc; 

(línea 27081) calcula el número de proceso del invocador. El trabajo real se efectúa pasando el número de tarea y un 
apuntador al mensaje a calltask, que veremos en breve. Dev opcl también se usa para cerrar los mismos dispositivos. 
De hecho, la única diferencia entre las funciones de abrir y cerrar en el nivel de esta función está en lo que sucede 
después del retomo de call task. 

Otras funciones que se invocan a través de la estructura dmap incluyen ttyopen y ttyclose, que dan servicio a las 
líneas en serie, y cttyopen y ctty cióse, que dan servicio a la consola. La última de éstas, ctty cióse, es casi una rutina 
ficticia; lo único que hace es devolver una situación OK incondicionalmente. 

La llamada al sistema SETSID requiere cierto trabajo por parte del sistema de archivos, trabajo que lleva a cabo 
do setsid (línea 27164). Una llamada al sistema, ioctl, se maneja primordialmente en device.c. Esta llamada se puso 
ahí porque está íntimamente ligada a la interfaz con las tareas. Cuando se efectúa un ioctl, se invoca doJíoctt para que 
construya un mensaje y lo envíe a la tarea correcta. 

En los programas escritos de modo que se ajusten al estándar POSix, se debe invocar una de las funciones 
declaradas en include/termios.h para controlar dispositivos de terminal. La biblioteca de C traducirá tales funciones a 
llamadas ioctl. En el caso de dispositivos distintos de las terminales, ioctl se utiliza para muchas operaciones, que en 
su mayor parte se estudiaron en el capítulo 3. 

La siguiente función es la única función PRÍVATE de este archivo. Se trata definddev (línea 27228), un pequeño 
procedimiento auxiliar que extrae los números de dispositivos principal y secundario de un número de dispositivo 
completo. 

La lectura y escritura reales en la mayor parte de los dispositivos pasa por call task (línea 27245), que dirige un 
mensaje a la tarea apropiada en la imagen del kemel mediante una llamada a sendrec. El intento puede fracasar si la 
tarea está tratando de revivir un proceso como respuesta a una solicitud anterior. Con toda seguridad, éste será un 
proceso distinto de aquel a cuyo nombre se está efectuando la solicitud actual. Call task exhibe un mensaje en la 
consola si se recibe un mensaje inapropiado. Es de esperar que tales mensajes no aparecerán durante el funcionamiento 
normal de MINIX, pero podrían presentarse si se intenta desarrollar un nuevo controlador de dispositivo. 

El dispositivo /dev/tty no existe físicamente; es una ficción a la cual cualquier usuario de un sistema multiusuario 
puede hacer referencia sin tener que determinar cuál de todas las terminales posibles está en uso. Cuando es necesario 
enviar un mensaje que hace referencia a /dev/tty, la siguiente función, callctty (línea 27311), encuentra los dispositivos 
principal y secundario correctos y los sustituye en el mensaje antes de reenviarlo a través de callJtask. 

La última función del archivo es no dev (línea 27337), que se invoca desde ranuras en la tabla para las cuales no 
existe un dispositivo, por ejemplo cuando se hace referencia a un dispositivo 



SEC. 5.8 


RESUMEN 


503 


de red en una máquina sin apoyo de red. No dev devuelve una situación de ENODEV, y evita caídas cuando se accede a 
dispositivos inexistentes. 

5.7.8 utilerías generales 

El sistema de archivos contiene unos cuantos procedimientos de utilería de propósito general que se emplean en varios 
lugares y que están reunidos en el archivo utility.c. 

El primer procedimiento es clock time (línea 27428), que envía mensajes a la tarea del reloj para obtener el tiempo 
real vigente. El siguiente procedimiento, fetchname (línea 27447) es necesario porque muchas llamadas al sistema 
tienen un nombre de archivo como parámetro. Si el nombre de archivo es corto, se incluye en el mensaje que el usuario 
envía al sistema de archivos; 

si es largo, se coloca en el mensaje un apuntador al nombre, el cual está en el espacio del usuario. Fetch name verifica 
ambas posibilidades, y en todos los casos obtiene el nombre. 

Dos funciones de este archivo manejan clases generales de errores. Nosys es el manejador de errores que se invoca 
cuando el sistema de archivos recibe una llamada al sistema que no es una de las suyas. Panic exhibe un mensaje y le 
dice al kemel que tire la toalla cuando algo catastrófico sucede. 

Las últimas dos funciones, conv2 y conv4, existen para ayudar a minix a resolver el problema de los órdenes de byte 
diferentes en los procesadores Intel y Motorola. Estas rutinas se invocan cuando se lee de o se escribe en una estructura 
de datos de disco, como un nodo-i o un mapa de bits. El orden de byte que usa el sistema que creó el disco está 
registrado en el superbioque; si es diferente del orden que el procesador local emplea, se intercambiará. El resto del 
sistema de archivos no necesita tener conocimiento del orden de byte en el disco. 

El último archivo es putk.c, que contiene dos procedimientos, ambos relacionados con la exhibición de mensajes. 
No es posible usar los procedimientos de biblioteca estándar, porque envían mensajes al sistema de archivos. Los 
procedimientos de putk.c envían mensajes directamente a la tarea de la terminal. Vimos un par de funciones casi 
idénticas en la versión de este archivo incluida en el administrador de memoria. 


5.8 RESUMEN 

Visto desde fuera, un sistema de archivos es una colección de archivos y directorios, junto con operaciones para 
manejarlos. Podemos leer y escribir archivos, crear y destruir directorios, y pasar archivos de un directorio a otro. La 
mayor parte de los sistemas de archivos modernos utiliza un sistema de directorios jerárquico en el que los directorios 
pueden tener subdirectorios ad infmitum. 

Visto desde el interior, un sistema de archivos tiene un aspecto muy distinto. Los diseñadores de un sistema de 
archivos deben preocuparse por la forma de asignar almacenamiento, y del mecanismo para saber siempre qué bloque 
corresponde a cuál archivo. Vimos además que los diferentes sistemas tienen diferentes estructuras de directorio. La 
confiabilidad y el rendimiento del sistema de archivos también son cuestiones importantes. 



504 


SISTEMAS DE ARCHIVOS 


CAP. 5 


La seguridad y la protección son asuntos vitales tanto para los usuarios como para los diseñadores de un sistema de 
archivos. Comentamos algunas fallas de seguridad en sistemas viejos y los problemas genéricos que muchos sistemas 
padecen. Además, estudiamos la verificación de autenticidad, con y sin contraseñas, listas de control de acceso y 
capacidades, así como un modelo de matriz para razonar acerca de la protección. 

Por último, estudiamos con detalle el sistema de archivos de minix, que es grande pero no complicado. Este sistema 
acepta solicitudes de trabajo de los procesos de usuario, consulta una tabla de apuntadores a procedimientos, e invoca el 
procedimiento apropiado para ejecutar la llamada al sistema solicitada. Gracias a su estructura modular y a su posición 
fuera del kemel, el sistema de archivos se puede sacar de minix y utilizarse como servidor de archivos autónomo con 
sólo efectuar algunas modificaciones menores. 

Internamente, el sistema de archivos de minix coloca los datos en buffers de un caché de bloques y trata de leer por 
adelantado cuando obtiene acceso secuencial a un archivo. Si el caché tiene el tamaño suficiente, la mayor parte del 
texto de programa se encontrará en la memoria durante las operaciones que acceden repetidamente a un conjunto dado 
de programas, como en una compilación. 


PROBLEMAS 

1. Dé cinco nombres de ruta distintos para el archivo /etc/passwd. (Sugerencia: no olvide las entradas de directorio 
y"..".) 

2. Los sistemas que manejan archivos secuenciales siempre cuentan con una operación para "rebobinar" archivos. ¿Los 
sistemas que manejan archivos de acceso aleatorio también la necesitan? 

3. Algunos sistemas operativos ofrecen una llamada al sistema rename para dar un nuevo nombre a un archivo. ¿Hay 
alguna diferencia entre el empleo de esta llamada para cambiar el nombre de un archivo y la táctica de copiar el 
archivo en un nuevo archivo con el nuevo nombre, borrando después del archivo viejo? 

4. Considere el árbol de directorios de la Fig. 5-7. Si /usr/jim es el directorio de trabajo, indique el nombre de ruta 
absoluto del archivo cuyo nombre de ruta relativo es Jast/x. 

5. La asignación contigua de archivos da pie a fragmentación del disco, como se mencionó en el texto. ¿Se trata de 
fragmentación interna o extema? Haga una analogía con algo que se haya estudiado en el capítulo anterior. 

6. Cierto sistema operativo sólo permite un directorio, pero éste puede tener un número arbitrario de archivos con 
nombres arbitrariamente largos. ¿Podría simularse algo parecido a un sistema de archivos jerárquico? ¿Cómo? 

7. Se puede seguir la pista al espacio libre en disco empleando una lista libre o un mapa de bits. Las direcciones de 
disco requieren D bits. En el caso de un disco con B bloques, F de los cuales están libres, exprese la condición en la 
que la lista libre ocupa menos espacio que el mapa de bits. Si D = 16 bits, exprese su respuesta como un porcentaje 
del espacio en disco que debe estar libre. 

8. Se ha sugerido que la primera parte de todo archivo UNIX se almacene en el mismo bloque de disco que su nodo-i. 
¿De qué serviría esto? 
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9. El rendimiento de un sistema de archivos depende de la tasa de aciertos en caché (la fracción de los bloques 

requeridos que se encuentra en el caché). Si la satisfacción de una solicitud con un bloque que está en el caché tarda 
1 ms, en contraste con los 40 ms que tardaría si se requiriera una lectura de disco, deduzca una fórmula para el 
tiempo medio de satisfacción de una solicitud si la tasa de aciertos es h. Grafique esta función para valores de h 
desde O hasta 1.0. 

10. Un disco flexible tiene 40 cilindros. Una búsqueda tarda 6 ms por cada cilindro que el brazo tiene que moverse. Si 
no se procura colocar los bloques de un archivo cercanos entre sí, dos bloques que lógicamente son consecutivos (es 
decir, que van seguidos en un archivo) estarán separados en promedio 13 cilindros. Por otro lado, si el sistema 
operativo intenta agrupar los bloques del mismo archivo, la distancia media entre bloques se puede reducir a dos 
cilindros (por ejemplo). ¿Qué tiempo tomaría leer un archivo de 100 bloques en ambos casos, si la latencia 
rotacional es de 100 ms y el tiempo de transferencia es de 25 ms por bloque? 

11. ¿Podría tener algún valor compactar periódicamente un disco? Explique. 

12. ¿Cómo podría modificarse tenex para evitar el problema de las contraseñas que se describió en el texto? 

13. Después de graduarse, usted solicita el puesto de director de un centro de cómputo universitario grande que acaba de 
deshacerse de su antiguo sistema operativo y ha cambiado a UNIX. Usted obtiene el puesto. Quince minutos después 
de entrar en funciones, su asistente irrumpe en su oficina gritando: 

"¡Unos estudiantes descubrieron el algoritmo que usamos para cifrar las contraseñas y lo acaban de pegar en un 
tablero de avisos!" ¿Qué debería hacer usted? 

14. El esquema de protección Morris-Thompson con números aleatorios de n bits se diseñó para que un intruso 
encontrara muy difícil descubrir un gran número de contraseñas cifrando previamente cadenas comunes. ¿Este 
esquema ofrece también protección contra un usuario estudiante que está tratando de adivinar la contraseña del 
superusuario en su máquina? 

15. Un departamento de ciencias de la computación tiene un gran número de máquinas UNIX en su red local. Los 
usuarios de cualquier máquina pueden emitir un comando de la forma 

machine4 who 

y hacer que se ejecute en machine4 sin tener que iniciar una sesión en la máquina remota. Esta capacidad se 
implementa haciendo que el kemel del usuario envíe el comando y su uid a la máquina remota. ¿Es seguro este 
esquema si todos los kemeis son confiables (p. ej., minicomputadores de tiempo compartido grandes con hardware 
de protección)? ¿Y si algunas de las máquinas son computadoras personales de estudiantes, sin hardware de 
protección? 

16. Cuando se elimina un archivo, sus bloques generalmente se colocan otea vez en la lista libre, pero no se borran. 
¿Cree usted que sería aconsejable hacer que el sistema operativo borre cada bloque antes de liberarlo? Considere 
factores tanto de seguridad como de rendimiento en su respuesta, y explique el efecto de cada uno. 

17. Tres mecanismos de protección que estudiamos son capacidades, listas de control de acceso y los bits rwx de UNIX. 
Para cada uno de los siguientes problemas de protección, indique cuál de estos mecanismos puede usarse. 

(a) Carlos quiere que todo mundo pueda leer sus archivos, excepto su compañero de oficina. 

(b) Miguel y Sergio quieren compartir algunos archivos secretos. 

(c) Linda quiere que algunos de sus archivos sean públicos. 

En el caso de UNIX, suponga que los grupos son categorías como profesores, estudiantes, secretarias, etcétera. 
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18. Considere el siguiente mecanismo de protección. A cada objeto y cada proceso se asigna un número. Un proceso 
sólo puede acceder a un objeto si éste tiene un número más alto que el proceso. ¿Cuál de los esquemas que 
describimos en el texto es parecido a éste? ¿En qué aspecto fundamental este mecanismo difiere de los esquemas 
del texto? 

19. ¿El ataque del caballo de Troya puede funcionar en un sistema protegido con capacidades? 

20. Dos estudiantes de ciencias de la computación, Carolina y Eugenia, están discutiendo acerca de los nodos-i. Carolina 
asegura que las memorias han crecido tanto y bajado tanto de precio que, cuando se abre un archivo, resulta más 
sencillo y rápido traer una copia nueva del nodo-i a la tabla de nodos-i que examinar toda la tabla para ver si ya está 
ahí. Eugenia no está de acuerdo. ¿Quién tiene la razón? 

21. ¿Qué diferencia hay entre un virus y un gusano? ¿Cómo se reproduce cada uno? 

22. Los enlaces simbólicos son archivos que apuntan indirectamente a otros archivos o directorios. A diferencia de los 
enlaces ordinarios como los que actualmente se implementan en MINIX, un enlace simbólico tiene su propio nodo- 
i, que apunta a un bloque de datos. Este bloque contiene la ruta del archivo al que se está enlazando, y el nodo-i 
permite que el enlace tenga dueño y permisos diferentes de los del archivo al que se enlaza. Un enlace simbólico y 
el archivo o directorio al que apunta pueden estar en dispositivos diferentes. Los enlaces simbólicos no forman parte 
del estándar POSix de 1990, pero se espera que se agregarán a POSix en el futuro. Implemento enlaces simbólicos 
para minix. 

23. Usted se da cuenta de que el límite de tamaño de 64 MB para los archivos MINIX no es suficiente para sus 
necesidades. Extienda el sistema de archivos de modo que aproveche el espacio no utilizado de los nodos-i para un 
bloque de triple indirección. 

24. Indique si el establecimiento de ROBUSThace al sistema de archivos más o menos robusto en caso de una caída. 
Todavía no se ha investigado cuál es el caso en la versión actual de minix, así que la respuesta podría ser afirmativa 
o negativa. Estudie bien lo que sucede cuando un bloque modificado se desaloja del caché. Tenga en cuenta que un 
bloque de datos modificado puede ir acompañado de un nodo-i y mapa de bits modificados. 

25. El tamaño de la tabla filp se define actualmente como una constante, NRFILPS, enfs/const.h. A fin de dar cabida a 
más usuarios en un sistema conectado en red, usted desea aumentar NRPROCS en inelude/ minix/config.h. ¿Cómo 
debe definirse NR FILPS en función de NR_PROCS A 

26. Diseñe un mecanismo que permita apoyar un sistema de archivos "ajeno", de modo que sea posible, por ejemplo, 
montar un sistema de archivos MS-DOS en un directorio del sistema de archivos minix. 

27. Suponga que ocurre un importante avance tecnológico que permite contar con RAM no volátil, que conserva su 
contenido de forma confiable después de una interrupción de la alimentación eléctrica, al mismo precio y con el 
mismo rendimiento que la RAM convencional. ¿Qué aspectos del diseño de sistemas de archivos resultarían 
afectados por este avance? 



6 


LISTA DE LECTURAS Y BIBLIOGRAFÍA 


En los cinco capítulos anteriores tratamos diversos temas. El presente capítulo pretende ser una ayuda para los lectores 
interesados en llevar más lejos su estudio de los sistemas operativos. La sección 6.1 es una lista de lecturas 
recomendadas. La sección 6.2 es una bibliografía alfabética de todos los libros y artículos citados en este libro. 

Además de las referencias que se dan, los Proceedings of the n-th ACM Symposium on Operating Systems 
Principies (ACM), que se celebra cada dos años, y los Proceedings ofthe n-th International Conference on Distributed 
Computing Systems (IEEE), que se celebra cada año, son buenos lugares para buscar artículos recientes sobre sistemas 
operativos. Lo mismo puede decirse del Symposium on Operating Systems Design and Implementation de USENIX. 
Además, dos publicaciones que suelen contener artículos sobre el tema sonACM Transactions on Computer Systems y 
Operating Systems Review. 

6.1 SUGERENCIAS DE LECTURAS ADICIONALES 6.1.1 Introducción y trabajos 
generales 

Brooks, The Mythical Man-Month: Essays on Software Engineering 

Libro ingenioso, divertido e informativo sobre cómo no escribir un sistema operativo, cuyo autor es alguien que 
aprendió a la fuerza. Atestado de buenos consejos. 
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Comer, Operating System Design. The Xinu Approach 

Un libro acerca del sistema operativo Xinu, que se ejecuta en la computadora LSI-11; contiene una exposición 
detallada del código fuente, incluido un listado completo en C. 

Corbató, "On Building Systems That Will Fail" 

En su conferencia por el Premio Turing, el padre del tiempo compartido aborda muchas de las mismas cuestiones 
que Brooks trata en su libro. La conclusión de Corbató es que todos los sistemas complejos tarde o temprano fallan, y 
que, para tener la mínima posibilidad de éxito es absolutamente indispensable evitar la complejidad y buscar la sencillez 
y la elegancia en el diseño. 

Deitel, Operating Systems, 2a. ed. 

Libro de texto general sobre sistemas operativos. Además del material estándar, esta obra contiene estudios de caso 
de UNIX, MS-DOS, MVS, VM, OS/2 y el sistema operativo de Macintosh. 

Finkel, An Operating Systems Vade Mecum 

Otro texto general sobre sistemas operativos; tiene una orientación práctica, está bien escrito y cubre muchos de los 
temas tratados en este libro, por lo que es un buen sitio para buscar una forma distinta de ver el mismo tema. 

IEEE, Information Technology—Portable Operating System Interface (POSIX), Parí 1: System Application Program 
Interface (API) [C Language] 

Éste es el estándar. Algunas partes incluso son muy claras, sobre todo el Anexo B, "Rationale and Notes", que con 
frecuencia ilumina las razones por las que las cosas se hicieron como se hicieron. Una ventaja de referirse al documento 
norma es que, por definición, no hay errores. Si un error tipográfico en el nombre de una macro pasó por el proceso de 
edición, ya no es un error, es oficial. 

Lampson, "Hints for Computer System Design" 

Butler Lampson, uno de los principales diseñadores de sistemas operativos innovadores en el mundo, ha reunido 
muchos consejos, sugerencias y pautas de sus años de experiencia y los ha incluido en este entretenido e informativo 
artículo. Al igual que el libro de Brooks, se trata de una lectura obligatoria para todo aspirante a diseñador de sistemas 
operativos. 

Lewine, POSIX Programmer's Guide 

Este libro describe el estándar POSIX en una forma mucho más comprensible que el documento de la norma misma, 
e incluye explicaciones sobre cómo convertir programas anteriores a POSIX y cómo crear nuevos programas para el 
entorno POSIX. Hay numerosos ejemplos de código, incluidos varios programas completos. Se describen todas las 
funciones de biblioteca y archivos de cabecera requeridos por POSIX. 

Silberschatz y Galvin, Operating System Concepts, 4a. ed. 

Otro texto sobre sistemas operativos que abarca procesos, administración de memoria, archivos y sistemas 
distribuidos. Se presentan dos estudios de casos: UNIX y Mach. La portada está 
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llena de dinosaurios. Qué tiene que ver esto con los sistemas operativos de la década de 1990 no queda claro. 

Stallings, Operating Systems, 2a. ed. 

Un texto más sobre sistemas operativos que trata todos los temas usuales y además incluye un poco de material 
sobre sistemas distribuidos y un apéndice sobre teoría de colas. 

Stevens, Advanced Programming in the UNIXEnvironment 

Este libro explica cómo escribir programas en C que usan la interfaz de llamadas al sistema de UNIX y la biblioteca 
estándar de C. Los ejemplos se basan en las versiones System V Reléase 4 y 4.4BSD de UNIX. Se describe con detalle la 
relación entre estas implementaciones y POSIX. 

Switzer, Operating Systems, A Practical Approach 

Un enfoque similar al de este texto. Los conceptos teóricos se ilustran con ejemplos en seudocódigo y una buena 
parte del código fuente en C de tunix, un sistema operativo modelo. A diferencia de minix, tunix no está pensado para 
ejecutarse en una máquina real; opera en una máquina virtual. Este sistema no es tan realista como minix en su 
tratamiento de los controladores de dispositivos, pero va más lejos que minix en otras direcciones, como en la 
implementación de la memoria virtual. 


6.1.2 Procesos 

Andrews y Schneider, "Concepts and Notations for Concurrent Programming" 

Un tutorial y reseña de los procesos y la comunicación entre procesos, incluidas espera activa, semáforos, 
monitores, transferencia de mensajes y otras técnicas. El artículo muestra también cómo se incorporan estos conceptos 
en diversos lenguajes de programación. 

Ben-Ari, Principies of Concurren! Programming 

Este librito está dedicado en su totalidad a los problemas de la comunicación entre procesos. Hay capítulos sobre 
exclusión mutua, semáforos, monitores y el problema de la cena de filósofos, entre otros. 

Dubois et al., "Synchronization, Coherence and Event Ordering in Multiprocessors" 

Un tutorial sobre sincronización en sistemas multiprocesador con memoria compartida. Sin embargo, algunas ideas 
aplican igualmente a los sistemas monoprocesador y con memoria distribuida. 

Silberschatz y Galvin, Operating System Concepts, 4a. ed. 

Los capítulos 4 a 6 tratan los procesos y la comunicación entre procesos, incluidos planificación, semáforos, 
monitores y problemas clásicos de comunicación entre procesos. 
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6.1.3 Entrada/salida 

Chen et al., "RAID: High Performance Reliable Secondary Storage" 

El empleo de múltiples unidades de disco en paralelo para E/S rápida es una tendencia en los sistemas más grandes. 
Los autores analizan esta idea y examinan diferentes organizaciones en términos de rendimiento, costo y confiabilidad. 

Coffinan et al., "System Deadlocks" 

Una introducción corta a los bloqueos mutuos, sus causas y las formas de prevenirlos o detectarlos. 

Finkel, An Operating Systems Vade Mecum, 2a. ed. 

El capítulo 5 trata el hardware de E/S y los controladores de dispositivos, sobre todo para terminales y discos. 

Geist y Daniel, "A Continuum of Disk Scheduling Algorithms" 

Se presenta un algoritmo generalizado de planificación del brazo del disco. Se proporcionan amplios resultados de 
simulaciones y experimentos. 

Holt, "Some Deadlock Properties of Computer Systems" 

Una análisis de los bloqueos mutuos. Holt presenta un modelo de grafos dirigidos que puede servir para analizar 
algunas situaciones de bloqueo mutuo. 

IEEE, revista Computer, marzo de 1994 

Este número de Computer contiene ocho artículos sobre E/S avanzada, y cubre simulación, almacenamiento de alto 
rendimiento, caches, E/S para computadoras paralelas y multimedia. 

Isloor y Marsiand, "The Deadlock Problem: An OverView" 

Tutorial sobre bloqueos mutuos, con hincapié especial en los sistemas de bases de datos. Se tratan diversos 
modelos y algoritmos. 

Stevens, "Heuristics for Disk Drive Positioning in 4.3BSD" 

Un estudio detallado del rendimiento de disco en Berkeley UNIX. Como suele suceder en los sistemas de 
computadora, la realidad es más complicada de lo que predice la teoría. 

Wiikes et al., "The HPAutoRAID Hierarchical Storage System" 

RAID (arreglo redundante de discos de bajo costo) es un importante avance en el área de los sistemas de disco de 
alto rendimiento. En él, un arreglo de discos pequeños colabora para producir un sistema con gran ancho de banda. Los 
autores describen con cierto detalle el sistema que construyeron en los laboratorios de HP. 
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6.1.4 Administración de memoria 

Denning, "Virtual Memory" 

Artículo clásico sobre muchos aspectos de la memoria virtual. Denning fue uno de los pioneros en este campo, e 
inventó el concepto de conjunto de trabajo. 

Denning, "Work Sets Past and Present" 

Una buena reseña de numerosos algoritmos de administración de memoria y paginación. Se incluye una 
bibliografía muy completa. 

Knuth, The Art of Computer Programming, vol. 1 

En este libro se analizan y comparan los algoritmos de administración de memoria de primer ajuste, mejor ajuste y 
otros. 

Silberschatz y Galvin, Operating System Concepts, 4a. ed. 

Los capítulos 8 y 9 se ocupan de la administración de memoria, incluidos intercambio, paginación y segmentación. 
Se mencionan diversos algoritmos de paginación. 


6.1.5 Sistemas de archivos 

Denning, "The United States vs. Craig Neidorf' 

Cuando un joven hacker descubrió y publicó información sobre el funcionamiento del sistema telefónico, fue 
acusado de fraude por computadora. Este artículo describe el caso, que implicó muchas cuestiones fundamentales, 
incluida la libertad de expresión. El artículo va seguido de algunas opiniones en contra y de una refutación por parte de 
Denning. 

Hafher y Markoff, Cyberpunk 

El reportero de cómputo del New York Times que reveló la noticia del gusano de Internet y su esposa, también 
periodista, relatan tres historias absorbentes de jóvenes hackers que se han introducido en computadoras por todo el 
mundo. 

Harbron, File Systems 

Un libro sobre diseño, aplicaciones y rendimiento de sistemas de archivos. Se cubren tanto la estructura como los 
algoritmos. 

McKusick et al; "A Fast File System for unix" 

El sistema de archivos de UNIX se reimplementó por completo para la versión 4.2 BSD. Este artículo describe el 
diseño del nuevo sistema, haciendo hincapié en su rendimiento. 
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Silberschatz y Galvin, Operating System Concepts, 4a. ed. 

Los capítulos 10 y 11 tratan los sistemas de archivos, y cubren operaciones con archivos, métodos de acceso, 
semántica de consistencia, directorios, protección e implementación, entre otros temas. 

Stallings, Operating Systems, 2a. ed. 

El capítulo 14 contiene una buena cantidad de material acerca del entorno de seguridad, sobre todo en lo que se 
relaciona con hackers, virus y otras amenazas. 
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+++++++++4include/ansi.h 


00000 /* La cabecera <ansi.h> intenta decidir si el compilador se ajusta lo suficiente a 
00001 * Standard C para que Minix lo aproveche. Si es asi, el símbolo _ANSI se define 

00002 * (como 31415). Si no, _ANSI no se define aquí, pero podrían definirlo aplicaciones 
00003 * que no deseen respetar estrictamente las reglas. El número mágico de la 
00004 * definición es para inhibir esto si no es muy necesario. (Por consistencia 
00005 * con las nuevas pruebas "#ifdef_ANSI" en las cabeceras, _ANSI realmente 
00006 * debía definirse como nada, pero eso afectaría muchas rutinas de biblioteca 
00007 * que usan "#if _ANSI".) 

00008 

00009 * Si se define _ANSI, se define la macro 
00010 

00011 * _PROTOTYPE(function, params) 

00012 * 

00013 * es definido. Esta macro se expande de diferentes formas, generando prototipos 
00014 * ANSÍ Standard C o bien prototipos K&R (Kernighan & Ritchie) a la antigua, 

00015 * según sea necesario. Algunos programas usan _CONST, _VOIDSTAR, etc., de tal 
00016 * manera que son portátiles a compiladores tanto ANSÍ como K&R. Aquí se definen 
00017 * las macros apropiadas. 

00018 */ 

00019 

00020 #ifndef_ANSI_H 
00021 ffdefine _ANSI_H 
00022 

00023 #if _STDC_ == 1 

00024 #define_ANSI 31459 /* compilador dice ajustarse plenamente a ANSÍ */ 

00025 #endif 
00026 

00027 ffifdef _GNUC_ 

00028 ffdefine _ANSI 31459 /* gcc se ajusta suficiente, aun en modo no ANSÍ */ 

00029 ffendif 
00030 

00031 ffifdef _ANSI 
00032 

00033 /* Guardar todo para prototipos ANSÍ. */ 

00034 ffidefine _PROTOTYPE(function, params) function params 

00035 #define _ARGS(params) params 

00036 

00037 ffdefine _VOIDSTAR void * 

00038 ffdefine _VOID void 

00039 ffdefine _CONST const 

00040 ffdefine _VOLATILE volatile 

00041 ffdefine _SIZET size_t 

00042 

00043 #else 
00044 

00045 /* Desechar los parámetros para prototipos K&R. */ 

00046 #define _PROTOTYPE(function, params) function() 

00047 ffidefine _ARGS(params) () 

00048 

00049 #define_VOIDSTAR void* 

00050 #define _VOID void 

00051 ffdefine _CONST 

00052 ffdefine _VOLATILE 

00053 ffdefine _SIZET int 
00054 
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00055 #endif /* _ANSI */ 

00056 

00057 ffendif /* ANSÍ H */ 
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#define EBADMODE 

( SIGN 53) 

/* modo erróneo en iocti */ 

00281 

ffdefine EWOULDBLOCK 

( SIGN 54) 


00282 

ffdefine EBADDEST 

(SIGN 55) 

/* dirección de destino no válida */ 

00283 

#define EDSTNOTRCH 

( SIGN 56) 

/* destino no alcanzable */ 

00284 

#define EISCONN 

( SIGN 57) 

/* todos listos conectados */ 

00285 

#define EADDRINUSE 

( SIGN 58) 

/* dirección en uso */ 

00286 

ffdefine 

( SIGN 59) 


00287 

ffdefine ECONNRESET 

( SIGN 60) 

/* conexión restablecida */ 

00288 

ffdefine ETIMEDOUT 

( SIGN 61) 

/* conexión vencida */ 

00289 

#define EURG 

( SIGN 62) 

/* datos urqentes presentes */ 

00290 

ffdefine ENOURG 

( SIGN 63) 

/* no hay datos urqentes presentes */ 

002 91 

ffdefine ENOTCONN 

( SIGN 64) 

/* no hay conexión (aún o ya) */ 

00292 

ffdefine ESHUTDOWN 

( SIGN 65) 

/* escritura a conexión de apaqado */ 

00293 

ffdefine ENOCONN 

(SIGN 66) 

/* no hay tal conexión */ 

00294 




'«©95 

/* Los siguientes no 

son errores 

POSIX, pero pueden ocurrir. */ 

00296 

ffüefine ELOCKED 

( SIGN 101) 

/* imposible enviar mensaje */ 

00297 

ffdefine EBADCALL 

(SIGN 102) 

/* error al enviar/recibir */ 

00298 




««299 

1/* Los siguientes códigos de erro: 

r los qenera el kernel mismo. */ 

00300 

ffifdef SYSTEM 



00301 

#define E BAD DEST 

-1001 

/* dirección de destino ileqal */ 

00302" 

ffdefine E BAO SRC 

-1002 

/* dirección de origen ilegal */ 

00303 

♦ define E TRY AGAlrfYl. 

-1003 

/* imposible enviar: tablas llenas */ 

00304 

ffdefine EOVERRUN 

-1004 

/* interrupción para tarea que no espera */ 

00305 

ffdefine EBADBUF 

-1005 

/* buf. mensaje fuera de esp. dir. del emisor */ 

«©•306 

♦define E TASK 

-1006 

/* imposible enviar a la tarea */ 

00307 

♦define E NOMESSAGE 

-1007 

/* RECEIVE falló: no hay mensaje */ 

00308 

ffdefine E NO PERM 

-1008 

/* usuarios ordin. no pueden enviar a tareas */ 

00309 

♦define E BAD FCN 

-1009 

/* únicos fen válidos son SEND, RECEIVE, BOTH */ 

00310 

♦define E BAD ADDR 

-1010 

/* dirección mala dada a rutina de utileria */ 

00311 

♦define E BAD PROC 

-1011 

/* núm. proc. erróneo dado a utilería */ 

00312 

ffendif /* SYSTEM */ 

00313 

1 1 

00314 

♦endif /* ERRNOH */ 


00400 

00401 

00402 

00403 

00404 

00405 


/* La cabecera <unistd.> contiene constantes diversas manifiestas. */ 

ffifndef _UNISTD_H 
#define _UNISTD_H 

/* POSIX requiere size_t y ssize_t en <unistd.h> y otros lugares. */ 
#¡fndef _SIZE_T 
ffdefine _SIZE_T 
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00486 

ffendif 




00487 





00488 

PROTOTYPE( 

void exit, (int status) 

) 


00489 

PROTOTYPE( 

int access, (const char *path, int amode) 

) 


00490 

PROTOTYPE( 

unsigned int alarm, (unsigned int seconds) 

) 


00491 

PROTOTYPE( 

int chdir, (const char *path) 

) 


00492 

PROTOTYPE( 

int chown, (const char * path, Uidt owner, Gidt group) 

) 


00493 

PROTOTYPE( 

int cióse, (int fd) 

) 


00494 

PROTOTYPE( 

char *ctermid, (char *s) 

) 


00495 

PROTOTYPE( 

char "cuserid, (char *s) 

) 


00496 

PROTOTYPE( 

int dup, (intfd) 

) 


00497 

PROTOTYPE( 

int dup2, (int fd, int fd2) 

) 


00498 

PROTOTYPE( 

int execi, (const char * path, const char *arg, ...) 

) 


00499 

PROTOTYPE( 

int execle, (const char * path, const char *arg,...) 

) 


00500 

PROTOTYPE( 

int execlp, (const char "file, const char *arg, ...) 

) 


00501 

PROTOTYPE( 

int execv, (const char *path, char *const argv[]) 

)_ 


00502 

PROTOTYPE( 

int execve, (const char *path, char "const argv[], 



00503 


char "const envp[]) 

V 


00504 

PROTOTYPE( 

int execvp, (const char "file, char "const argv[|) 

) 


00505 

PROTOTYPE( 

pidtfork, (void) 

) 


00506 

PROTOTYPE( 

long fpathconf, (int fd, int ñame) 

) 


00507 

PROTOTYPE( 

char "getcwd, (char "buf, sizet size) 

) 


00508 

PROTOTYPE( 

gidt getegid, (void) 

) 


00509 

PROTOTYPE( 

uidt geteuid, (void) 

) 


00510 

PROTOTYPE( 

gidt getgid, (void) 

) 


00511 

PROTOTYPE( 

int getgroups, (int gidsetsize, gidt grouplistQ) 

) 


00512 

PROTOTYPE( 

char "getlogin, (void) 

) 


00513 

PROTOTYPE( 

pidt getpgrp, (void) 

) 


00514 

PROTOTYPE( 

pidt getpid, (void) 

) 


00515 

PROTOTYPE( 

pidt getppid, (void) 

) 


00516 

PROTOTYPE( 

uidt getuid, (void) 

) 


00517 

PROTOTYPE( 

int isatty, (int fd) 

) 


00518 

PROTOTYPE( 

int link, (const char * existing, const char *new) 

) 


00519 

PROTOTYPE( 

offt Iseek, (int fd, offt offset, int whence) 

) 


00520 

PROTOTYPE( 

long pathconf, (const char "path, int ñame) 

) 


00521 

PROTOTYPE( 

int pause, (void) 

) 


00522 

PROTOTYPE( 

int pipe, (int fildes[2]) 

) 


00523 

PROTOTYPE( 

ssizet read, (int fd, void "buf, sizet n) 

) 


00524 

PROTOTYPE( 

int rmdir, (const char "path) 

) 


00525 

PROTOTYPE( 

int setgid, (Gidt gid) 

) 


00526 

PROTOTYPE( 

int setpgid, (pid t pid, pidt pgid) 

) 


00527 

PROTOTYPE( 

pidt setsid, (void) 

) 


00528 

PROTOTYPE( 

int setuid, (Uidt uid) 

) 


00529 

PROTOTYPE( 

unsigned int sieep, (unsigned int seconds) 

) 


00530 

PROTOTYPE( 

long sysconf, (int ñame) 

) 


00531 

PROTOTYPE( 

pidt tcgetpgrp, (int fd) 

) 


00532 

PROTOTYPE( 

int tcsetpgrp, (int fd, pidt pgrpid) 

) 


00533 

PROTOTYPE( 

char "ttyname, (int fd) 

) 


00534 

PROTOTYPE( 

int unlink, (const char "path) 

) 
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00535 

00536 

00537 

00538 

00539 

00540 

00541 

00542 

00543 

00544 

00545 

00546 

00547 

00548 

00549 

00550 

00551 

00552 

00553 

00554 

00555 

<ft85£7 
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00630 

PROTOTYPEÍ 

sizet strcspn, (const cha | r| * si, const char | *s2) 1) 

00631 

PROTOTYPEÍ 

char *strerror, (int ermuinj 1 ) 

00632 

PRO' 

roí 

'YPE( 

sizet strlen, (const char 1 *s )) 

00633 

PRO' 

roí 

YPE( 

char *strncat, (char *s1, 

const char *s2, 

sizet n) 

J_ 

00634 

PRO' 

roí 

'YPE( 

char *strncpv, (char *s1, 

const char * s2, 

size t n) 

) 

00635 

1 PROTOTYPEÍ 

char *strpbrk, (const char 

*s1, const char 

*s2) 

) 

00636 

PRO' 

roí 

'YPE( 

char *strrchr, (const char 

*s, int c) 

)_ 

00637 

PRO' 

roí 

'YPE( 

sizet strspn, (const char 

*s1, const char * s2) 

J_ 

00638 

PRO' 

roí 

'YPE( 

char *strstr, (const char 

1 si, const char* S2) 

) 

00639 

PROTOTYPEÍ 

char *strtok, (char * si, 

const char * s2)) 

00640 

PROTOTYPEÍ 

sizet strxfrm, (char *s1 

i 1 const char *s2, 1 sizet nU 

00641 



1 

00642 

ffifdef MINIX ! 

00643 

1/* Para compatibilidad hacia atrás. */ 1 

00644 

PRO' 

roí 

'YPE( 

char *index, (const char * 

s, int charwanted) 

)_ 

00645 

PRO' 

roí 

'YPE( 

char *rindex, (const char 

*|s, int charwanted) 

)_ 

00646 

PRO' 

roí 

'YPE( 

void bcopv, (const void * 

src, void *dst, s 1 

izet lenqth) 

) 

00647 

PROTOTYPEÍ 

int bcmp, (const void *s1 


const void *s2, 

sizet lenqth) 

) 

00648 

PROTOTYPEÍ 

void bzero, (void *dst, si 

zet lenath) 


U _ 

00649 

PROTOTYPEÍ 

void *memccpv, (char *dst 


const char *src 

, int ucharstop 

i 

00650 






) 

00651 

/* Funciones 

BSD*/ 





00652 

PROTOTYPEÍ 

int strcasecmp, (const char 

*s1, const char 

*s2) 

j _ 

00653 


1 




00654 






00655 

|#endif/* STRINGH */ | 


+++++++++++++++++++++++++++++++++++include/signal.h+++++ 

/* La cabecera <signal.h> define todas las señales ANSI y POSIX. MINIX reconoce 

* todas las señales requeridas por POSIX; se definen en seguida. También se 

* reconocen algunas señales adicionales. 


ffifndef _SIGNAL_H ffdefine _SIGNAL_H 
#ifndef _ANSI_H ffindude <ansi.h> ffendif 

/* Éstos son los tipos más vinculados con el manejo de señales. */ typedef int sig_atoirilc_t; 

ffifdef _POSIX_SOURCE 
ffifndef _SIGSET_T 
ffdefine _SIGSET_T 
typedef unsigned long sigset_t; 

#endif 

#endif 

16 /* número de señales empleadas */ 1 /* colgar */ 

ffdefine _NSIG 


'define SIGHUP 
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00725 #define 0St3INT 2 /*= interrupción (DEL) *;/ 

00726 #define SIGQUIT 3 /* abandonar (ASCII FS) */ 

00727 #define SIGILL 4 /* instrucción ilegal */ 

00728 ffdefine SIGTRAP 5 /* trampa rastreo (no restab. si se atrapa) */ 

00729 #define SIGABRT 6 /* instrucción IOT */ 

00730 ffdefine SIGIOT 6 /* SIGABRT para quienes hablan PDP-jKÍ; */ 

00731 ffdefine SIGUNUSED 7 /* código "de repuesto" */ 

#0732 ffdefine SIGFPE 8 /* excepción de punto flotante */ 

00733 #define S'IGKILL 9 /* kill (no puede atraparse ni ignorarse) *•/ 

00734 #define STGUSR1 10 /* usuario definió señal # 1 */ 

D'0'735 ffdefine SIGSEGV 11 /* violación de segmentación */ 

0073'6 fdefine SIGUSR2 12 /* usuario definió señal # 2 */ 

00737 #define STGPIPE 13 /* escritura en conducto sin lector */ 

00738 ffdefine SIGALRM 14 /* reloj de alarma */ 

00739 fdefine SIGTERM 15 /* señal de term. de kill en software */ 

0074 0 

00741 ffdefine SIGEMT 7 /* obsoleto */ 

00742 #define SIGBUS 10 /* obsoleto */ 

00743 

00744 /* POSIX requiere que se definan las señales siguientes, aunque no 
00745 * estén apoyadas. Aqui están las def in.icicr.es, pero no están apoyadas. 

00746 */ 

00747 #define SIGCHLD 17 /* proc. hijo terminado o detenido */ 

00*748 ffdefine SIGCONT 18 /* continúe si está detenido */ 

00749 ffdefine STGSTO? 19 /* señal de paro */ 

00750 #define STGTS7? -20 /* señal de paro interactiva *-/ 

00751 #define SIGTTIN 21 /'* proceso segundo plano quiere leer */ 

OOf^i' #define SIGTTOU 22 /’* proceso segundo plano quiere escr. */ 

00753 

00754 /* No se permite el tipo sighandler_t si no se define_POSIX_SOURCE. */ 

00755 (tifdef _POSIX_SOURCE 

00756 #define _sighandler_t sighandler_t 

00707 ffelse 

00758 typedef yoid (*_sighandler_t) (int); 

0075 9 #endi«; 

00760 

É07-61 /* Macros empleadas como apuntadores a funciones. */ 

00762 #define SIG_ERR ((_sighandler_t) -1) /* devolución de error */ 

00763 #define S;B3_®FL ((_sighandler_t) 0) /* manejo de señales por omisión */ 
00764 #define SIG_IGN ((_sighandler_t) 1) /* ignorar señal */ 

00765 #define SIG_H0LD ((_sighandler_t) 2) /* bloquear señal */ 

00766 #define SIG_CATCH ((_sighandler_t) 3) /* atrapar señal "*/ 

00767 

00768 #ifdef _POSIX_SOURCE 
#0769 struct sigaction { 

00770 _sighandler_t sa_handler; /* SIG_DFL, SIG_IGN o apuntador a fuñe. */ 

00771 sigset_t sa_mask; /* señales a bloquear durante manejador */ 

00772 int sa_flags; /* banderas especiales */ 

00773 } ; 

00774 

00775 /* Fields for sa_flags. */ 

00776 fdefine SA_ONSTACK 0x0001 /* entregar señal en pila alterna */ 

•00777 #define SA_RESETHAND 0x0002 /* restab. manej. señales si señal atrapada */ 
00778 #define SA_NODEFER 0x0004 /* no bloquear señal al atraparla */ 

00779 ffdefine SA_RESTART 0x0008 /* reinicio aut. de llamada al sist. */ 

00780 ffdefine SA_SIGINFO 0x0010 /* manejo de señales extendido */ 

00781 ffdefine SA_NOCLDWAIT 0x0020 /* no cree zombis */ 

00782:;0define SA_NQe¿0S!FOP 0x0040 /* no reciba SX<3ifí3;X.O cuando hijo pare */ 

00783 

00784 /* POSIX requiere estos valores para usarlos con sigprocmask(2), */ 








































#define 
ffdefine EX!' 
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01010 

01011 

01012 

01013 

01014 

01015 

01016 

01017 

01018 

01019 

01020 

01021 

01022 

01023 

01024 

01025 

01026 

01027 

01028 

01029 

01030 

01031 

01032 

01033 

01034 

01035 

01036 

01037 

01038 

01039 

01040 

01041 

01042 

01043 

01044 

01045 

01046 

01047 

01048 

01049 

01050 

01051 

01052 

01053 

01054 

01055 

01056 

01057 

01058 

01059 

01060 

01061 

01062 

01063 

01064 

01065 

01066 

01067 

01068 

01069 


32767 /* valor 

#define RAND_MAX 
A define MB CUR 
MAX 


máx. generado por rand() */ 

1 /* valor máx. de carácter mu 

typedef struct { int quot, rem; } 
typedef struct { long quot, rem; 


Itibyte en 
} ldiv_t; 


MINIX */ 


/* Los tipos son size_t, wchar_t, d±v_t y ldiv_t. */ 
ffífndef _size_t 

#define _SIZE_T 

typedef unsigned int size_t; /* tipo devuelto por sizeof */ 
ffendif 


fifndef _WCHAR_T 

#define _WCHAR_T typedef char wcha r_t; 

#endif 

/* tipo conjunto de caracteres expandido 
/*■ Prototipos de */ 

funciones. */ ffifndef 
_ANSI_H 

#include <ansi.h> 

#endi|É 


_PROTOTYPE( void abort, (void) _PROTOTYPE( 
abs, (int _j) 

_PROTOTYPE( int atexit, (void (*_fune)(void)) 
double atof, (const char *_nptr) 

(const char *_nptf) 

char *_nptr) ) 


int 

) _PROTOTYPE( 

) _PROTOTYPE( int atoi, 

) _PROTOTYPE( long atol, (const 
^PROTOTYPE( void *calloc, (size_t _nmemb, 

) _PROTOTYPE ( div_t $Xv, (int ^¿rlumer, iíi't _denom) 

) _PROTOTYPE ( void exit, (int _status) ) 

_PROTOTYPE( void free, (void *_ptr) ) _PROTOTYPE( 

char *getenv, (const char *_name) ) _PROTOTYPE( long labs, 

(long _j) ) _PROTOTYPE( ldiv_t Idiv, (long 

_numer, long _denom) ) _PROTOTYPE( void *malloc, (size_t _size) 

) _PROTOTYPE( int mblen, (const char *_s, size_t _n) ) 

_PROTOTYPE( size_t mbstowcs, (wchar_t *_pwcs, const char *_s, size_t _n)) _PROTOTYPE( 
int mbtowc, (wchar_t *_pwc, const char *_s, size_t _n) ) _PROTOTYPE( iht rand, 

(void) ) _PROTOTYPE( void *realloc, (void 

*_ptr, size_t _size) ) _PROTOTYPE( void srand, (unsigned int _seed) 

) _PROTOTYPE( double strtod, (const char *_nptr, char **_endptc) ) 

_PROTOTYPE( long strtol, (const char *_nptr, char **_endptr, ”int _base) ) _PROTOTYPE( 
int System, (const char *_string) ) _PROTOTYPE( size_t 

wcstombs, (char *_s, const wchar_t *_pwcs, size_t _n)) _PROTOTYPE( int wctomb, (char 
*_s, wcharwchar) ) _PROTOTYPE( void *bsearch, (const void 

*_key, const void *_base, 

size_t _nmemb, size_t _size, 

int (*compar) (const void *, const void *)) ) _PROTOTYPE i 

void qsort; (void *_base, size_t _nmeinb, size_t _size, 

int (*compar) (const void *, const void *)) ) _PROTOTYPE( 

unsigned long int strtoul, 

(const char *_nptr, char **_endptr, int _base) ) 


#ifdef _MINIX 

_PROTOTYPE( int putenv, (const char *_name) 

_PROTOTYPE( jfct getopt, (int _argc, char **_argv, char *_opts))¡ 

extern char *optarg; 

extern int optind, opterr, optopt; 
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01210 

#define TCIOFLUSH 3 /* vaciar datos entrada y salida acumul. 

7 

01211 



01212 

/* Valores de action para tcflow(). POSIX Seo. 7.2.2.2. 7 


01213 

ffdefine TCOOFF 1 /* suspender salidas 7 


01214 

#define TCOON 2 /* reiniciar salidas suspendidas 7 


01215 

ffdefine TCIOFF 3 /* transmitir car. STOP por la linea 7 


01216 

#define TCION 4 /* transm. car. START por la línea 7 


01217 



01218 



01219 

/* Prototipos de funciones. 7 


01220 

ffifndef ANSIH 


01221 

ffinclude <ansi.h> 


01222 

ffendif 


01223 



01224 

PROTOTYPE( int tcsendbreak, (int fildes, int duration) 

) 

01225 

PROTOTYPE( int tcdrain, (int filedes) 

) 

01226 

PROTOTYPE( int tcflush, (int Hiedes, int queue selector) 

) 

01227 

PROTOTYPE( int tcflow, (int filedes, int action) 

) 

01228 

PROTOTYPE( speedt cfgetispeed, (const struct termios *terniiosp) 

) 

01229 

prototype( speedt cfgetospeed, (const struct termios *termiosp) 

) 

01230 

PROTOTYPE( int cfsetispeed, (struct termios ’terniiosp, speedt speed) 

) 

01231 

PROTOTYPE( int cfsetospeed, (struct termios *termiosp, speedt speed) 

) 

01232 

PROTOTYPE( int tcgetattr, (int filedes, struct termios * termios p) 

) 

01233 

PROTOTYPE( int tcsetattr, \ 


01234 

(int filedes, int optactions, const struct termios *termiosp)) 

01235 



01236 

ffdefine cfgetispeed(termiosp) ((teriniosp)->cispeed) 


01237 

#define cfgetospeed(termiosp) ((termiosp)->cospeed) 


01238 

ffdefine cfsetispeed(termiosp, speed) ((termiosp)->cispeed = (speed), 

0) 

01239 

ffdefine cfsetospeed(termiosp, speed) ((termiosp)->cospeed = (speed), 0) 

01240 



01241 

#ifdef MINIX 


01242 

/* Aquí están las extensiones locales al estándar POSIX para Minix. 


01243 

* Los programas que se ajusten a Posix no pueden acceder a ellas, 


01244 

* asi que sólo se definen cuando se compila un programa Minix. 


01245 

7 


01246 



01247 

/* Extensiones al mapa de bits ciflag de termios. 7 


01248 

ffdefine IXANY 0x0800 /* cualquier tecla p/continuar salidas 7 

01249 



01250 

/* Extensiones al mapa de bits c ofiag de termios. Sólo están activas si 


01251 

* OPOST está habilitado 7 


01252 

#define ONLCR 0x0002 /* Convertir NL en CR-NL en salidas 7 


01253 

#define XTABS 0x0004 /* Expandir tabs a espacios 7 


01254 

#define ONOEOT 0x0008 /* desechar EOT ("D) en salidas 7 


01255 



01256 

/* Extensiones al mapa de bits dflag de termios. 7 


01257 

#define LFLUSHO 0x0200 /* Vaciar salidas 7 


01258 



01259 

/* Extensiones al arreglo c ce 7 


01260 

ffdefine vreprint 11/* ce c[vreprint] ("R) 7 


01261 

ffdefine VLNEXT 12 /* cccjVLNEXTj ('V) 7 


01262 

#define VDISCARD 13 /* ccc[VDISCARD] ("O) 7 


01263 



01264 

/* Extensiones a las tasas de bauds. 7 


01265 

#define B57600 0x0100 /* 57600 baud 7 


01266 

ffdefine BU 5200 0x0200 /* 115200 baud 7 


01267 



01268 

/* Éstos son los valores predeterminados que usa el kernel y ’stty sane' 

7 

01269 
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01274 

#define TSPEEDDEF 

B9600 



01275 





01276 

ffdefine TEOF DEF 

'\4' /* 

”D 

7 

01277 


POS IX VDISAB 

TE 

01278 

ffdefine' 

'ERASEDEF 

VIO'/* 

"H 

*/ 

01279 

ffdefine' 

'INTRJ3EF 

YI777* 

"? 

7 

01280 

ffdefine' 

-KILL DEF 

•\25’ /* 

"U 

7 

01281 

l#define TMIN DEF ! 

1 



01282 

ffdefine 1 

■QUIT DEF 

•\34' /* 

"\ 

7 

01283 

#define 1 

-START DEF 

•\21 ’ /* 

"Q 

7 

01284 

#define 1 

■STOP DEF 

•\23' /* 

’S 

7 

01285 

|#define TSUSPDEF 1 

'\32' /* 

"7 

7 

01286 

#define' 

'TIME DEF 

0 



01287 

#define' 

■REPRINT DEF 

*\22" /* 

"R 

7 

01288 

#define' 

’LNEXT DEF 

•\26’ /* 

"V 

7 

01289 

ffdefine TDISCARDDEF 

'\177* 

"0 

*/ 

01290 





01291 

/* Tamaño de ventana. Esta ir 

iformación se qu 

arda en el controlador TTY pero no se usa 

01292 

* Se puede usar para 

aplicaciones 1 

bas< 

adas en pantalla en un entorno de ventanas 

01293 

* Se pueden usar los 

iocti TIOCGWIN 

sz 

v TIOCSWINSZ para obtener v fiiar esta 

01294 





01295 

7 




01296 





01297 

struct winsize 




01298 

{ 




01299 

unsiqned short 

wsrow; 


/* filas, en caracteres 7 

01300 

unsiqned short 

wscol; 


/* columnas, en caracteres 7 

01301 

unsiqned short 

wsxpixel; 


/* tamaño horizontal, pixeles 7 

01302 

unsiqned short 

wsvpixel; 


/* tamaño vertical, pixeles 7 

01303 

I; 




01304 

#endif /* MINIX*/ 




01305 





01306 

1 ffendif /* TERMIOSFI */ ! 


01401 

01402 

01403 

01404 



+++++++++++++++++++++++++include/a.out.h++++++++++++++++ 

/* .Es cabecera <a.out> describe el formato de los archivos 


ejecutable; 


ffifndef _AOüT_ 8 
#define AOOT H 
struct éxec { 

l'üns.ighéíi char a_magic[2]; 
unsigned char a_flags; 
unsigned cha.t a_cpu; 
unsigned char a_hdrlen; 
unsigned char a_ur.usea; 
unsigned short a versión,* 
long a_text; 


/* número mágico */ 

/*banderas, véase adelante */ 

/* id de cpu */ 

/*longitud de cabecera */ 

/* reservado p/uso futuro */ 

/*sello de versión (no se usa) */ 
/*tamaño de segm. texto, bytes */ 
/*tamaño de seguí, datos, bytes */ 
/*tamaño de segm. bss, bytes */ 
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01415 

long aentry; /* punto de entrada 7 

01416 

long atotal; /* total de memoria asignada 7 

01417 

long asyms; /* tamaño de tabla de símbolos 7 

01418 


01419 

/* FORMA CORTA TERMINA AQUÍ 7 

01420 

long atrsize; /* tamaño reubicación de texto 7 

01421 

long adrsize; /* tamaño reubicación de datos 7 

01422 

long atbase; /* base reubicación de texto 7 

01423 

long a dbase; /* base reubicación de datos 7 

01424 

}; 

01425 


01426 

ffdefine A MÁGICO (unsigned char) 0x01 

01427 

ffdefine A MAGIC1 (unsigned char) 0x03 

01428 

#define BADMAG(X) ((X) .amagicjO] !=AMAGIC0 ; ¡ (X) ,amagic[1 ] != AMAGIC1 

01429 


01430 

/* Id de CPU de máq. OBJETIVO (orden de bytes codificado en dos bits de orden bajo) 

01431 

ffdefine A NONE 0x00 /* desconocido 7 

01432 

ffdefine A 18086 0x04 /* intel 18086/8088 7 

01433 

ffdefine AM68K OxOB /* motorola m68000 7 

01434 

ffdefine ANS16K 0x00 /* national semiconductor 16032 7 

01435 

ffdefine AI80386 0x10 /* intel Í80386 7 

01436 

#define ASPARC 0x17 /* Sun SPARC 7 

01437 


01438 

#define ABLR(cputype) ((cputype&óxói)!=0) /* TRUE si bytes izq. a der. 7 

01439 

ffdefine AWLR(cputype) ((cputype&0x02)!=0) /* TRUE si palabras izq. a der. 7 

01440 


01441 

/* Banderas. 7 

01442 

#define AUZP 0x01 /* página(s) cero sin mapa 7 

01443 

ffdefine APAL 0x02 /* ejecutable alineado por página 7 

01444 

ffdefine ANSYM 0x04 /* tabla de símbolos al estilo nuevo 7 

01445 

#define AEXEC 0x10 /* ejecutable 7 

01446 

A define A8EP 0x20 /* l/D separados 7 

01447 

ffdefine APURE 0x40 /* texto puro 7 /* no se usa 7 

01448 

ffdefine ATOVLY 0x80 /* superpos. texto 7 /* no se usa 7 

01449 


01450 

/* Distancias de varias cosas. 7 

01451 

ffdefine A MINHDR 32 

01452 

#define ATEXTPOS(X) ((long)(X).ahdrlen) 

01453 

ffdefine ADATAPOS(X) (A TEXTPOS(X) + (X).a text) 

01454 

ffdefine A HASRELS(X) ((X).a hdrien > (unsigned char) A MINHDR) 

01455 

ffdefine A HASEXT(X) ((X).a hdrien > (unsigned char) (A MINHDR + 8)) 

01456 

ffdefine A HASLNS(X) ((X).a hdrien > (unsigned char) (A MINHDR + 16)) 

01457 

ffdefine A HASTOFF(X) ((X).a hdrien > (unsigned char) (A MINHDR + 24)) 

01458 

ffdefine ATRELPOS(X) (ADATAPOS(X) + (X).adata) 

01459 

ffdefine ADRELPOS(X) (ATRELPOS(X) + (X).atrsize) 

01460 

#define A SYMPOS(X) (A TRELPOS(X) + (A HASRELS(X) ? \ 

01461 

((X).atrsize + (X).adrsize): 0)) 

01462 


01463 

struct reloe { 

01464 

long rvaddr; /* dir. virtual de la referencia 7 

01465 

unsigned short rsymndx; /* núm. seg. interno o núm. simb. externo 7 

01466 

unsigned short r type; /* tipo de reubicación 7 

01467 

}; 

01468 


01469 

/* valores de r type: 7 

01470 

ffdefine R ABBS 0 

01471 

ffdefine R RELLBYTE 2 

01472 

#define RPCRBYTE 3 

01473 

ffdefine R RELWORD 4 

01474 

ffdefine RPCRWORD 5 
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01484 

#define SBSS 

((unsigned 

short)-4) 

01485 





01486 

struct nlist f 


/* 

entrada de tabla de símbolos 7 

01487 

char nnamef81 

i 

/* 

nombre de símbolo 7 

01488 

lonq nvalue; 


/* 

valor */ 

01489 

unsiqned char 

nsdass; 

/* 

clase de almacenamiento 7 

01490 

unsiqned char 

nnumaux; 

/* 

núm. entradas aux. (no se usa) 7 

01491 

unsiqned snort 

ntvDe; 

/* 

base lenquaie v tipo deriv. (no se usa) 7 

01492 

}; 




01493 





01494 

/* Bits baios de 

clase de almacenam 

iento (sección). 7 

01495, 

ffdefine NSECT 

07 

/* 

máscara de sección 7 

01496 

#define NUNDF 

00 

/* 

no definida 7 

01497 

#define N ABS 

01 

/* 

absoluta 7 

01498 

ffdefine N TEXT 

02 

/* 

texto */ 

01499 

#define N DATA 

03 

/* 

datos 7 

01500 

ffdefine NBSS 

04 

/* 

bss 7 

01501 

#define NCOMM 

05 

/* 

(común) 7 

01502 





01503 

/* Bits altos de 

clase de almacenam 

iento. 7 

01504 

#define N CLASS 

0370 

/* 

máscara de clase de almac. 7 

01505 

#define C NULL 




01506 

ffdefine CEXT 

0020 

r 

símbolo externo 7 

01507 

#define CSTAT 

0030 

/* 

estático */ 

01508 





01509 

/* Prototipos de 

funciones. 

*/ 


01510 

#ifndef ANSIH 




01511 

#include <ansi.h> 

01512 

#endif 




01513 





01514 

PROTOTYPEf int 

nlist, (char 

•file 

, struct nlist *nl)): 

01515 





01516 

#endif /* AOUT 

H 7 




Hnclude/sys/types.t 


01600 

01601 

01602 

01603 

01604 

01605 

01606 

01607 

01608 

01609 


/*La cabecera <sys/types.h> contiene definiciones de tipos de datos importante; 

* Se considera buena práctica de programación usarlas en lugar 

* del tipo base subyacente. Por convención, todos los nombres 


TYPESJH TYPESH 

ffifnde 

f /* _ANSI se usa de alguna manera para determinar si el compilador es o bd< 

ffdefin 
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-inelude/sys/ioctl.h- 


01800 

01801 

01802 

01803 

01804 

01805 

01806 

01807 

01808 

01809 


/* La cabecera ioctl.h declara operaciones de control de dispositivos. */ 

ffifndef _IOCTL_H 
#define _IOCTL_H 

#if _EM_WSIZE >== A 

/* Los iocti tienen el comando codificado en la palabra de orden bajo, 

* y el tamaño dél parámetro en la de orden alto. Los 3 bits altos de la palabra 

* de orden alto codifican lgt Situación in/out/void del parámetro. 


01810 

01811 

01812 

01813 

01814 

01815 

01816 

01817 

01818 

01819 

01820 

01821 

01822 

01823 

01824 

01825 

01826 

01827 

01828 

01829 

01830 

01831 

01832 

01833 

01834 

01835 

01836 

01837 

01838 

01839 

01840 

01841 

01842 

01843 

01844 

01845 

01846 

01847 

01848 

01849 

01850 

01851 

01852 

01853 

01854 


#define _¿iocparm_mask 

#define _IOC_VOID OxIfff ffdefine 

IOCTYPE MASK 

ídefine IlOC_IN 0XFFFF 

#define _IOC_OüT 
#define _IOC_INODT 


#def iné , _IO(x,y) 

ffdefine _IOW(x,y,t) 


#else 

/* No hay codificación, 
máquina de 16 bits. */ 


(JOCJN IOC OUT) ffdefine 

£{x «8) ; y ¡ _IOC_VOID) ((x « 

& _IOCPARM_MASK) «16) ;\ 

_IOCPARM_MASK) « 16) ¡\ 

_IOC_IN) ((x « 8) ! y ; 

_IOCPARM_MASK) « 16) !\ 

IOC INOUT) 


#define _IO(x,y) 

#define _IOR(x,y,t) 

#define _IOW(x,y,t) ffdefine _IORW(x,y,t) ffendif 


:OR(x,y,t) 

8) ¡ y ¡ ((sizeof(t) 
((sizeof(t) & 

((Sizeof(t) & 


ffdefine _IORW(x,y,t) 


complicada en una 


((x « 8) ¡ y) 


/* loctis de IO(x 

terminal. ffdefine 
TCGET-S ffdefine 
TCSETS ffdefine * 

TCSETSW ffdefine 
TCSETSF ffdefine- IOR( 

TCSBRK ffdeff|i& IOW( 

TCDRAIN ffdefine IOW( 

TCFLOW '-define TCFLSH IOW( 

ffdefine TIOCGWINSZ IOW( 

#define TIOCSWINSZ -10 ( 

#define TIOCGPGRP IOW( 

#define TIOCSPGRP IOW( 

^define TIOCSFON IOR( 

IOW( 

# de fine' ÍIOCGETP IOW( 

# define TIOCSETP IOW( 

ffdefine fipCGBIC IOW( 

#define TIOCSETC 


■y) 


'T 1 , 8, struct termios) 

•T, 9, struct termios) 

T 1 , 10, struct termios) 

•T, 11, struct termios) 

•T, 12, int) 

'T 1 , 13) 

•T, 14, int) 

T, 15, int) 

T, 16, struct winsize) 

T, 17, struct winsize) 

•T, 18, int) 

T, 19, int) 

T, 20, u8t [8192]) 


/*tegetattr */ 

/* tesetattr, TCSANOW */ 

/* tesetattr, TCSADRAIN */ 
/*tesetattr, TCSAFLUSH */ 

/*tcsendbreak */ 

/* tedrain */ 

/*tcflow */ 

/*teflush */ 


IOR( 1 t 1 
IOW('t 1 
’lOR ( 1 1 1 


1, struct sgttyb) 

2, struct sgttyb) 

3, struct tchars) 

4, struct tchars) 
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01855 






01856 

/* loctis de red. 7 





01857 

ffdefine NWIOSETHOPT 

IOW('n 

1 

16, 

struct nwioethopt) 

01858 

ffdefine NWIOGETHOPT 

IOR('n 

T 

17, 

struct' nwioethopt) 

01859 

ffdefine NWIOGETHSTAT 

IOR('n 


18, 

struct nwioethstat) 

01860 






01861 

ffdefine NWIOSIPCONF 

IOW('n 


327 

struct nwioipconf) 

01862 

A define NWIOGIPCONF 

IOR('n 

j~ 

337 

struct nwioipconf) 

01863 

ffdefine NWIOSIPOPT 

IOW('n 

) 

34, 

struct nwioipopt) 

01864 

#define NWIOGIPOPT 

IOR('n 

i 

35, 

struct nwioipopt) 

01865 






01866 

#define NWIOIPGROUTE 

IORW(' 

ívT 

40, struct nwio route) 

01867 

ffdefine NWIOIPSROUTE 

IOW(' 

n', 

41 

, struct nwio route) 

01868 

ffdefine NWIOIPDROUTE 

IOW(' 

n', 

42, struct nwio route) 

01869 






01870 

ffdefine NWIOSTCPCONF 

IOW('n 

T~ 

48, 

struct nwiotcpconf) 

01871 

ffdefine NWIOGTCPCONF 

IOR('n 

T~ 

49, 

struct nwiotcpconf) 

01872 

ffdefine NWIOTCPCONN 

IOW('n 

T~ 

507 

struct nwiotcpcl) 

01873 

ffdefine NWIOTCPLISTEN 

IOW('n 

i 

51, 

struct nwiotcpcl) 

01874 

ffdefine NWIOTCPATTACH 

IOW('n 

V” 

527 

struct nwiotcpatt) 

01875 

ffdefine NWIOTCPSHUTDOWN 

10 (’n 


537 


01876 

ffdefine NWIOSTCPOPT 

IOW('n 

i 

54, 

struct nwiotcpopt) 

01877 

ffdefine NWIOGTCPOPT 

IOR('n 

i 

55, 

struct nwiotcpopt) 

01878 






01879 

ffdefine NWIOSUDPOPT 

IOW('n 

s~ 

647 

struct nwioudpopt) 

01880 

#define NWIOGUDPOPT 

IOR('n 

T~ 

657 

struct nwioudpopt) 

01881 






01882 

/* loctis de disco. 7 ¡ 

01883 

#define DIOCEJECT 

10 (’d 

i 

5) 


01884 

ffdefine DIOCSETP 

IOW('d 

i 

6, 

struct partition) 

01885 

#define DIOCGETP 

IOR('d 

T~ 

77” 

struct partition) 

01886 






01887 

/* loctis de teclado. 7 j 

01888 

#define KIOCSMAP 

IOW('k 1 1 

3^ 

keymapt) 

01889 

1 ^ i 

01890 

/* loctis de memoria 7 j 

01891 

ffdefine MIOCRAMSIZE 

IOW( ’in 

¡ 

3, 

u32t) /* Tamaño 

01892 

#define MIOCSPSINFO 

IOW('m 

i 

4, 

void *) 

01893 

ffdefine MIOCGPSINFO 

IOR('m 


5, 

struct psinfo) 

01894 






01895 

/* loctis de cinta magnética. * 

1 



01896 

ffdefine MTIOCTOP 

IOW('M 

T~ 

iT - 

struct mtop) 

01897 

ffdefine MTIOCGET 

IOR('M 

n 

27” 

struct mtget) 

01898 






01899 

/* Comando SCSI. 7 





01900 

ffdefine SCIOCCMD 

IOW('S 

j~ 

i7” 

struct scsicmd) 

01901 






01902 

/* loctis de CD-ROM. 7 ¡ 

01903 

ffdefine CDIOPLAYTI 

lORf'c 

i 

i, 

struct cdplaytrack) 

01904 

ffdefine CDIOPLAYMSS 

IOR('C 

i 

2, 

struct cdplaymss) 

01905 

ffdefine CDIOREADTOCHDR 

IOW('c 


37” 

struct cdtocentry) 

01906 

#define CDIOREADTOC 

IOW('c 

T~ 

4, 

struct cdtocentry) 

01907 

ffdefine cdioreadsubch 

IOW('c 

i 

5, 

struct cdtocentry) 

01908 

#define CDIOSTOP 

10 (’c 

) 

10) 


01909 

ffdefine CDIOPAUSE 

10 (*c 

) 

11) 

01910 

#define CDIORESUME 

10 (’c 

i 

12)1 

01911 

ffdefine CDIOEJECT 

DIOCEJECT 

01912 



01913 

/* loctis DSP de tarjeta 

de sonido. 7 

01914 

ffdefine DSPIORATE 

lORf's 1 1 


unsigned int) 
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01915 

#define DSPIOSTEREO 

IOR('s', 

2, ui 

nsigned 

int) 

01916 

ffdefine DSPIOSIZE 

IOR('s', 

3, cu 

nsigned 

int) 

01917 

#define DSPIOBITS 

IOR('s', 

4, u 

nsigned 

int) 

01918 

#define DSPIOSIGN 

IOR('s'. 

5,ui 

nsigned 

int) 

01919 

01920 

01921 

#define DSPIOMAX 
#define DSPIORESET 

IOW('s’, 

_IO ('s', 7) 

6, uj 

nsigned 

int) 

01922 

/* loctis de mezclador 

de tarjeta 

de sonido. 

*/ 


01923 #define MIXIOGETVOLUME IORW('s', 10 , struct volume level) 

01924 ffdefine MIXIOGETINPUTLEFT _IORW('S', 11 , struct inout ctri) 

01925 #define MIXIOGETINPUTRIGHT IORW('s', 12 , str-uct inoutctrl) 
01926 ffdefine MIXIOGETOUTPUT IORW('si, 13 , struct inout Ctfl) 

01927 #define MIXIOSETVOLUME IORW('s', 20 , struct volume level) 

01928 #define MIXIOSETINPUTLEFT _IORW('s', 21 , struct inout ctri) 

01929 ffdefine MIXIOSETINPUTRIGHT IORW('S', 22 , struct inout ctri) 

01930 ffdefine MIXIOSETOUTPUT IORW('S', 23 , struct inout ctri) 

01931 

01932 #ifndef ANSI 
01933 #include<ansi.h> 

01934 #endif 
01935 

01936 PROTOTYPE( int iocti, (int fd, intrequest , void *data) 

01937 

01938 #endif /* IOCTLH */ 

include/sys/sigcontext.h 


02000 #ifndef SIGGONTEXTH 
02001 #define SIGCONTEXTH 
02002 

02003 /* La estructura sigcontext es usada por la llamada sigretum(2). 

02004 * Los programas de usuario casi nunca invocan sigretumf), pero 

02005 * el mecanismo que atrapa señales puede usarla internamente. 

02006 */ 

02007 

02008 ffifhdef ANSIH 
02009 ffinclude <ansi.h> 

02010 #endif 
02011 

02012 ffi-fndef CONFIGH 
02013 #include <minix/config ,h> 

02014 #endif 
02015 

02016 #if !defined(CHIP) 

02017 ffinclude "error, configuration is not known" 

02018 #endif 
02019 

02020 /* La siguiente estructura debe coincidir con la estructura stackframeas empleada 
02021 * por el código de conmutación de contexto del kemei. Se deben agregar registros 

02022 * de punto flotante en un struct distinto. 

02023 */ 

02024 #if (CHIP == INTEL) 

02025 struct sigregs { 

02026 fti-fWORDSIZE;^4 
02027 short srgs; 

02028 short sr fs; 

02029 #endif /* WORD SI 7.F, — 4 */ 
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02090 struct sigreos scregs; /* conjunto de registros que restaurar */ 

02091 }; 

02092 

02093 #if (CHIP == INTEL) 

02094 #if WORD SIZE = 4 

02095 #define sc gs sc_regs,sr_gs 

02096 #define sc fs scregs.srfs 

02097 #endif /* WORD SI2E = 4*1 
02098 #defíne sc es segrega.sr es 

02099 #defíne sc ds scregs.ards 

02100 #deflne sc di sc regs.sr di 

02101 #defme sc si scregs.srsi 

02102 #defíne scíp scregs.srbp 

02103 #defme sc st sc regs.sr st /* tope de pila — se usa en kemel */ 

02104 #define sc bx sc regs.sr bx 
02105 #define sc dx sc regs.sr dx 

02106 #define sc cx sc regs.sr cx 
02107 #define sc retreg sc regs.sr retreg 

02108 #define sc retadr sc regs.sr retadr /* dirección de retomo al invocador 
02109 de save — se usa en kemel */ 

02110 #define sc_pc sc_regs.sr_pc 
02111 #define sc cs sc regs.sr cs 
02112 #define sc_psw sc_regs.sr_psw 
02113 #define sc sp sc regs.sr sp 
02114 #defme sc_ss sc_regs.sr_ss 
02115 #endif /* CHIP = INTEL */ 

02116 

02117 #if (CHIP = M68000) 

02118 #defíne sc A retreg sc reas.sr retreg 
02119 #defme sc dl segrega.sr dl 
02120 #define sc_d2 sc_regs.sr'_d2 
02121 #define sc_d3 sc_regs.sr_d3 
02122 #defíne se d4 se regs.sr d4 

02123 #define se_d5 sc_regs-sr_d5 

02124 #define sc_d6 sc A regs.sr_d6 
02125 #define sc_d7 sc_regs.sr_d7 
02126 #define sc aO sc regs.sr aO 
02127 #define se al sc regs.sr al 
02128 #define sc_a2 sc_regs.sr_a2 
02129 #define sc_a3 sc regs.sr_a3 
02130 #define sc_a4 sc_regs.sr_a4 
02131 #define sc_a5 sc_regs.sr_a5 

02132 #define sc íp se_regs.sr aó 

02133 #define sc sp sc regs.sr sp 
02134 #define sc_pc sc_regs.sr_pc 
02135 #defíne sc_psw sc_regs.sr_psw 
02136 #endif /* CHIP == M68000 */ 

02137 

02138 /* Valores para se_flags. Deben coincidir con <niinis</jmp_üuf.h>. */ 

02139 #defíne SC SIGCONTEXT 2 /* no cero si se incluye contexto de señal */ 

02140 #defíne SC NOREGLOCALS 4 /* no cero si. no se deben guardar 
02141 y restaurar los registros */ 

02142 

02143 _PROTQTYPE( int sigretum, (struct sigcontext *_scp) ); 

02144 

02145 ffendif /* SIGGONTEXT H */ 
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include/sys/ptrace.h 

02200 /* <sys/ptrace.h> 

02201 * definiciones para ptrace(2) 

02202 */ 

02203 

02204 -ifhdef PTRACE H 
02205 #define PTRACE H 
02206 

02207 #defíne T STOP -1 /* detener el proceso */ 

02208 #define T_OK 0 /* habilitar rastreo del padre de este proc. */ 

02209 #define TGETINS 1 /* devolver valor de espacio de instr- */ 

02210 #define T GETDATA 2 /* devolver valor de espacio de datos */ 

02211 #define T GETURSE 3 /* devolver valor de tabla proc. del usuario */ 

02212 #defíne T SETINS 4 /* fijar valor de espacio de instr. */ 

02213 #define T SETDATA 5 /* fijar valor de espacio de datos */ 

02214 #define T SETURSE 6 /* fijar valor en tabla proc. del usuario */ 

02215 #define T RESUME 7 /* reanudar ejecución */ 

02216 #define T EXIT 8 /* salir */ 

02217 #define T STEP 9 /* fijar bit de rastreo */ 

02218 

02219 /* Prototipos de funciones. */ 

02220 #ifndef_ANSI_H 
02221 #include <ansi.h> 

02222 #endif 
02223 

02224 _PROTOTYPE( long ptrace, (int _req, pidt _pid, long addr, long data)); 

02225 

02226 #endif /* PTRACEH*/ 
include/sys/stat.h 


92300 /" La cabecera <sys/stat.h> define un structque se usa en las funciones stat() y 
02301 * fstat. La información de este struct proviene del nodo-i de algún archivo. 

02302 * Éstas son las únicas llamadas aprobadas para inspeccionar nodos-i. 

02303 */ 

02304 

02305 #ifndef STAT H 
02306 #define A STATH 
82307 

02308 struct stat { 

02309 devt stdev; 

02310 inotstmo; 

02311 modet stmode; 

02312 short int stnlink 
02313 uidtstuid; 

02314 short int stgid, 

B2315 devt st A rdev; 

02316 offtstsize; 

02317 timet statime; 

02318 timet stmtime, 

02319 timet stctime; 


/*núm. disp. principal/secund, */ 

/* número de nodo-i */ 

/* modo de aren., bits protección, etc.*/ 

/* # vínculos; HACK TEMPORAL: debe ser nlinkt */ 
/* uid del dueño del archivo */ 

/* gid: HACK TEMPORAL: debe ser gidt */ 

/* tamaño de archivo */ 

/* tiempo de último acceso */ 

/* tiempo de últ. modif. de datos */ 

/* tiempo de últ. cambio de situac. aren. */ 
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02320 

02321 

02322 

02323 

02324 

02325 

02326 

02327 

02328 

02329 

02330 

02331 

02332 

02333 

02334 

02335 

02336 

02337 

02338 

02339 

02340 

02341 

02342 

02343 

02344 

02345 

02346 

02347 

02348 

02348 

02349 

2350 

02351 

02352 

02353 

02354 

02355 

02356 

02357 

02358 

02359 

02360 

02361 

02362 

02363 

02364 

02365 

02366 

02367 

02368 

02369 

02370 

02371 

02372 

02373 


}; 

/♦Definiciones de máscara tradicionales para stmode. */' 

/* Las mutaciones feas en algunas definiciones son para evitar extensiones de signo 
* sorprendentes como S IFREG != (mode t) S IFREG cuando los ints son de 32 bits. 

*/ 

#define S IFMT ((modet) 0170000) /* tipo de archivo */ 

#define S A IFREG ((modet) 0100000) /* normal */ 

#define SIFBLK 0060000 /* especial por bloques */ 

#define SIFDIR 0040000 /* directorio */ 

#define S IFCHR 0020000 /* especial por caracteres */ 

#define SIFIFO 0010000 /* éste es un FIFO */ 

#define SISUID 0004000 /* fijar id de usuario al ejecutar- */ 

#define SISGID 0002000 /* fijar id de grupo al ejecutar "/ 

/* siguiente reservado para uso futuro 7 
#define SISVTX 01000 /* guardar texto intercamü. aun desp. uso */ 


/* Máscaras POSIX para st mode. */ 


#defme S IRWXU 

00700 

/* dueño: 

rwx-*/ 

#define S IRUSR 

00400 

/* dueño: 

r -*/ 

#defme S IWÜSR 

00200 

/* dueño: 

- w -*/ 

#define SJXUSR 

00100 

/* dueño: 

-x--* 1 

#define S IRWXG 

00070 

/* grupo: 

—rwx— * / 

#define S IRQRP 

00040 

/* grupo: 

— r -*/ 

#define S IWGRP 

00020 

/* grupo: 

—-w- *1 

#define S IXGRP 

00010 

/* grupo: 

-X— */ 


#define S 

IRWXO 

00007 

/* otros: 

-rwx*/ 

#define S 

IROTH 

00004 

/* otros: 

- r —*/ 

#define S 

IWOTH 

00002 

/* otros: 

-, w _*/ 

#define S 

IXOTH 

00001 

/* otros: 

.x */ 


/* Estas macros prueban st mode (de POSIX Sec. 5.6.1.1). */ 


#define S ISREG(m) (((m) & S A IFMT) = S A IFREG) 
#define S ISDIR(m) f((m) & S IFMT) == S IFDIR) 
ffdefine S ISCHR(m) (((m) & S IFMT) = S IFCHR) 
ffdefine S ISBLK(m) (((m) & S IFMT) = S IFBLK) 
ffdefine S A ISFIFOfin) (((m) S SIFMT) == S A IFIFO) 


/* es aren, normal */ 

/* es directorio */ 

/* es esp. p/car. */ 

/* es esp. p/bloques 7 
/* es conducto/FIFO */ 


/* Prototipos de funciones. */ 

#ifndef ANSIH 
#include <ansi.h> 

#endif 

PROTOTYPE) int chmod, (const cnar *path, Modet mode)); 
PROTOTYPE) int fstat, (int fi-Ldes, struct stat *buf)); 
_PROTOTYP£( int mkdir, (const char *path, Modet mode)); 

PRQTOTYPE) int mkfifo, (const char *path, Mode A t mode)); 
_PROTOTYPE( int stat, (const char "path, struct stat *buf)); 
PROTOTYPE) modet umask, (Modet cmask)); 

#endif /* STATH */ 
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include/sys/dir.h 

02400 02401 /* La cabecera <dir.h> da la organización de un directorio. */ 

02402 #ifndef DIR H 
02403 #define DIRH 
02404 

02405 #defíne DIRBLKSIZ 512 /* tamaño de bloque de directorio */ 

02406 

02407 #ifndef DIRSIZ 
02408 #define DIRSIZ 14 
02409 #endif 
02410 

02411 s-tr-uct dir-ect { 

02412 inotdino; 

02413 chardnamefDIRSIZ]; 

02414 }; 

02415 

02416 #endif /* DIRH •/ 

inclucfe/ sys/wait.h 

02500 /* La cabecera <sys.wait.n> contiene macros relacionadas con wait(). El valor 
02501 * devuelto por wait() y waitpid() depende de si el proceso terminó por exit(), 

02502 * fue terminado por una señal o se detuvo por control de trabajos, como 

02503 * sigue: 

02504 * 

02505 * Byte alto Bytebajo 

02506 * +-+ 

02507 * exit(situac.) | situac. | 0 | 

02508 * +-+ 

02509 * terminado por señal | 0 | señal 

02510 * +-+ 

02511 * detenido (ctl. trab.) | situac. | 0 | 

02512 * +-+ 

02513 */ 

02514 

02515 #ifndef WAIT H 
02516 #define WAITH 
02517 

02518 #define LOW(V) ((v) & 0377) 

02519 #define A HIGH(v) (((V) » 8) & 0377) 

02520 

02521 #define WNOHANG 1 /* no esperar a que el hijo salga */ 

02522 #define WUNTRACED 2 /* para ctl. trab.; no implementado */ 

02523 

02524 #define WIFEXITED(s) (_LOW(s)=0) /* salida normal */ 

02525 #define WEXITSTATUS(s) (_HIGH(s)) /* situac. salida */ 

02526 #define WTERMSIG(s) (_LOW(S) & 0177) /* valor señal */ 

02527 #defíne WIFSIGNALED(S) (((unsigned int)(s)-l (LOW(s) == 0177) (high(s) & 0377) & BxFFFF) < OxFF) /* señalizado */ 
02528 #define WIFSTOPPED(S) (_LOW(s) = 0177) /* detenido */ 

02529 #defíne WSTOPSIG(s) (_HIGH(s) & 0377) /* señal de paro */ 
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02530 

02531 /* Prototipos de funciones. */ 

02532 #ifndef_ANSI_H 
02533 #include <ansi.h> 

02534 #endif 
02535 

02536 _PROTOTYPE( pidt wait, (int *_stat_loc) 

02537 _PROTOTYP£( pid t waitpid, (pid t _pid, int *_stat_loc, int options) 

02538 

02539 #endif /* WAITH */ 


include/minix/config.h 


02600 

02601 

02602 

02603 

02604 

02605 

02606 

02607 

02608 

02609 

02610 

02611 

02612 

02613 

02614 

02615 

02616 

02617 

02618 

02619 

02620 

02621 

02622 

02623 

02624 

02625 

02626 

02627 

02628 

02629 

02630 

02631 

02632 

02633 

02634 

02635 

02636 

02637 

02638 

02639 


#ifiidef CONFIG H 
#define GONFIQH 

/* Números de versión de Minix. */ 

#define OS RELÉASE "2.0" 

#define OSVERSION "0" 

/* Este archivo fija parámetros de config, para el kemel, FS y MM de MINIX. 

* Se divide en 2 secciones principales. La primera contiene parámetros ajustables 

* por el usuario. En la segunda se fijan varios parámetros internos del sistema 

* con base en los parámetros ajustables por el usuario. 

*/ 


/* tU. " 0 ^=^ .. pp ■ ■■ ^ ■ ■ gu ■ 

* Esta sección contiene parámetros ajustables por el usuario 


#define MACHINE 

IBMPC 

/* Debe ser uno de los nombres siguientes */ 

#define IBMPC 

1 

/* cualquier sistema 8088 u 80x86 */ 

#define SUN 4 

40 

/* cualquier sistema Sun SPARC */ 

#define SUN_4_60 

40 

/* Sun-4/60 (alias SparcStation 1 o Campus */ 

#define ATARI 

60 

/* ATARI ST/STe/TT (68000/68030) */ 

#define AMIGA 

61 

/* Commodore Amiga (68000) */ 

#define MACINTOSH 

62 

/* Apple Macintosh (68000) */ 


/* Tamaño de palabra en bytes (constante igual a sizeof(int)). */ 
#if _ACK_ 

#define WORD SIZE EM WSIZE 
#endif 


/* Si ROBUST es 1, se escriben en disco bloques de nodos-i, directorio e indirectos 

* del caché tan pronto como se modifican. Esto hace al FS más robusto pero más 

* lento. Si es 0, esos bloques no reciben tratamiento especial, y podría haber 

* problemas si se cae el sistema. 

*/ 

#define ROBUST 0 /* 0 para rapidez, i para robustez */ 

/* Núm. de ranuras de la tabla de procesos para procesos de usuario. */ 

#define NRPROCS 32 
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02640 

02641 /* El caché de buffers debe hacerse tan grande como sea costeable. */ 

02642 #if (MACHINE == IBMPC && WORDSIZE == 2) 

02643 #define NR BUFS 40 /* # núm. bloques en el caché */ 

02644 #defme NR BUF HASH 64 /* tamaño tabla disp. buf; DEBE SER POT. DE 2*1 

02645 #endif 

02646 

02647 #if (MACHINE == IBM PC && WORD SIZE == 4) 

02648 #define NR A BUFS 512 /* # núm. bloques en el caché */ 

02649 #defme NR BUF HASH 1024 /* tamaño tabla disp. buf.; DEBE SER POT. DE 2*1 

02650 #endif 

02651 

02652 #if (MACHINE = SUN_4_60) 

02653 #define NR BUFS 512 /*# núm. bloques en el caché (<=1536) */ 

02654 #defme NR BUF HASH 512 /* tamaño tabla disp, buf.; DEBE SER POT. DE 2*1 

02655 #endif 

02656 

02657 #if (MACHINE == ATARI) 

02658 #defíne NR BUFS 1536 /* # núm. bloques en el caché (<=1536) */ 

02659 #define NR BUF HASH 2048 /* tamaño tabla disp, buf.; DEBE SER POT. DE 2*1 

02660 #endif 

02661 

02662 /* Definiciones para la configuración del kemel. */ 

02663 #define AUTO BIOS 0 /* xt wini.c - usar BIOS autoconfig de Western */ 

02664 #define LINEWRAP 1 /* consolé.c - continuar lineas en col. 80 */ 

02665 #define ALLOW GAP MESSAGES 1 /* proc.c - permitir mensajes en espacio 

02666 * entre fin de bss y dir. de pila más baja */ 

02667 

02668 /* Habilitar o no el caché de segundo nivel del FS en el disco de RAM */ 

02669 #define ENABLE CACHE2 O 
02670 

02671 /* Incluir o exclub controladores de disp. 1 para inclub, 0 para exclub. */ 

02672 #define ENABLE NETWORKING 0 /* habilitar código TCP/IP */ 

02673 #define ENABLE AT WINI 1 /* habilitar conb. Winchester AT * { 

02674 #define ENABLE BIOS WINI 0 /* habilitar conb. Winchester BIOS */ 

02675 #define ENABLE ESDI WINI 0 /* habilitar conb. Winchester ESDI */ 

02676 #define ENABLE XT WINI 0 /* habilitar conb. Winchester XT */ 

02677 #define ENABLE ADAPTEC SCSI 0 /* habilitar conb. SCSI ADAPTEC •*/ 

02678 #define ENABLE MITSÜMI CDROM IM 0 /* habilitar conb. CD-ROM Mitsumi */ 

02679 #define ENABLE SB AUDIO 0 /* habilitar conb. audio Soundblaster 

02680 

02681 /* DMA SECTORS puede aumentarse para acelerar conboladores basados en DMA. */ 

02682 #define DUA SECTORS 1 /* Tamaño buf. DMA (debe ser >= 1) */ 

02683 

02684 /* inclub o excluir código para compatibilidad hacia atrás. */ 

02685 #define ENABLE BINCOMPAT 0 /* p/bmarios que usan llamadas obsoletas */ 

02686 #define ENABLE SRCCOMPAT 0 /* p/fuentes que usan llamadas obsoletas *7 
02687 

02688 /* Determinar qué dispositivo usar para conductos. */ 

02689 #define PIPE DEV ROOT DEV /* conductos en dispositivo raiz */ 

02690 

02691 /* NR CONS, NR RS LINES y NR PTYS determinan el número de terminales que el 

02692 * sistema puede manejar. 

02693 */ 

02694 #define NR CONS 2 /* # consolas de sistema (1 a 8) */ 

02695 #define NR RS LINES 0 /*# terminales rs232 (0,1 o 2) */ 

02696 #define NR PTYS 0 /* # seudoterminales (0 a 64) */ 

02697 

02698 #if (MACHINE == ATARI) 

02699 /* El sig. define dice si se tiene un 


ATARI ST o TT */ 
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02700 #defme ATARI TYPE TT 

02701 #defme ST 1 /* todos ST y Mega ST */ 

02702 #defme STE 2 /* todos STe y Mega STe */ 

02703 #defme TT 3 

02704 

02705 /* si SCREEN es 1 son posibles operacioness gráficas en pantalla */ 

02706 #define SCREEN 1 

02707 

02708 /* Este define dice si el teclado genera escapes VT100 o IBMPC. */ 

02709 #define KEYBOARD VT100 /* VT100 o bien IBM PC */ 

02710 #define VT100 100 

02711 

02712 /* El siguiente define determina el tipo de partición. */ 

02713 #define PARTITIONING SUFRA /* uno de los siguientes o ATARI */ 

02714 #define SUFRA 1 /*ICD, SUFRA y BMS son iguales */ 

02715 #define BMS 1 

02716 #define ICD 1 

02717 #define CBHD 2 

02718 #define EICKMANN 3 

02719 

02720 /* Definir número de unidades de disco duro en el sistema. */ 

02721 #define NR_ACSIJ)RIVES 3 /* típicamente 0 o 1 */ 

02722 #define NR SCSI DRIVES 1 /* típicamente 0 (ST, STe) o 1 (TT) */ 

02723 

02724 /* Algunos sistemas requieren un retardo breve después de cada comando Winchester; 
02725 * en ellos FASTDISK debe ser 0. Otros discos no lo necesitan, y puede ponerse 

02726 * FASTJ3ISK en 1 para evitar el retardo. 

02727 */ 

02728 #define FAST DISK 1 /* 0 o I */ 

02729 

02730 I* Mota: si quiere hacer más chico el kemel, puede hacer NR PD DRIVES r- 0. Aún 
02731 * podrá arrancar minix.img de disquete. Sin embargo, DEBERÁ traer los sistemas de 

02732 * archivos root y usr de un disco duro. 

02733 */ 

02734 

02735 /* Definir número de unidades de disquete en el sistema. */ 

02736 #define NR FD DRIVES 1 /* 0,1,2*/ 

02737 

02738 /* Este define de configuración controla el código de impresora en paralelo. */ 

02739 «define PAR PRINTER 1 /* inhab. (0)/hábil. (1) impr. paralelo */ 

02740 

02741 /* Este define de configuración controla código de reloj de contr. de disco. */ 

02742 #define HD CLOCK 1 /* inhab. (0) /hábil. (1) reloj disco duro */ 

02743 

02744 #endif 

02745 

02746 

02748 * No hay parámetros ajustables por el usuario después de esta linea * 

02750 /* Fijar tipo CHIP con base en la máquina escogida. CHIP indica más que sólo la 
02751 * CPU. P. ej., se espera que las máquinas con CHIP == INTEL tengan controladores 

02752 * de interrupciones 8259A y demás propiedades de las máquinas tipo IBM PC/XT/AT/ 

02753 * 386 en general. */ 

02754 #define INTEL 1 /* Tipo GHIP para PC, XT, AT, 386 y clones */ 

02755 #define M68000 2 /* Tipo CHIP para Atari, Amiga, tíacintosh */ 

02756 #define SPARC 3 /* Tipo CHIP para SUN-4 (p.ej. SPARCstation)*/ 

02757 

02758 /* Fijar tipo FP FORMAT con base en la máquina escogida, hw o bien sw */ 

02759 ffdefine FP NONE 0 /* no apoya punto flotante */ 
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027 60 (¡define I\P_ FÍESE- 1 /* se ajusta a norma T jilfe de pto. flot. */ 

02761 

02762 # i f (MAO BTÍf t =^.Í©M_PC) 

02763 #define CHIP INTEL 

027 64 (¡define SHADOWING 0 

027 65 #define ENABItE WINI (EMABliE^ATJ/íINI | | JÍJfjdiÍ^SlOS_WINI | | \ 

02766 ENABLE_ESDI_WINI || ENABLE_XT_WINI) 

027 67 #define ENABLE^SCSI (EKABI,K_ADA?TKG_SCS t) 

02768 #define ENABLE_CDROM (ENABLE_MITSUMI_CDROM) 

027 69 #define :E||Áa|tÉ^_AUDIO {ENAB1 Í E_SB_AUDI0) 

02770 #endif 
02771 

02772 #if (MACHI ICT ' =^ ^ARI) | | (MACHIljKf• == AMIGA) | | (MACHI1|8| == MACINTOSH) 

02773 #define CHIP M68000 

02774 (¡define SHADOWINQ 1 

02775 #endif 
02776 

02777 # i f (MA.CEB8R. =4#JN_4) ¡; (MACHll|¡t*:í== SUN_4_60) 

02778 #define CHIP SPARC 

02779 #define FP_FORMAT FP_IEEE 

02780 ¡f ce fine SHADOWING 0 

02781 #endif 
02782). 

02783 #if (MACHINE == ATARI)|| (MACHINE == SUN_4) 

02784 #define ASKDEV 1 /* preguntar por disp. de arranque */ 

02785 !fcefine FASTLOAD 1 /* usar múltiples transf. bloque para inic. ram */ 

02786 #endif 

02787 

02788 #if (ATARI_TYPE == TT) /* y demás 68030 */ 

02789 #define FPP 
02790 tundef SHADOWING 
02791 #define SHADOWING 0 
02792 #endif 
02793 

02794 #ifnde-f FP_FORMAT 

027 95 !fdefine FP_FORMAT FP_NOK'E 

02796 tendif 

02797 

02798 /* El archivo buf.h usa MAYBEJVRITE_IMMED. */ 

02799 #if ROBUST 

02800 # de fine MAYBE WRITE_IMMED WRÍfjl IMMED /* más lento pero quizá más seguro */ 
02801 #else 

02802 (¡define MAYBl_WRITE_IMMED 0 /* más rápido */ 

02803 (¡enci f 

02804 

02805 #ifnde-f MACHINE:' , 

02806 error "In <minix/config.h> piease define MACHINE" 

02807 tendif 

02808 

02809 tifndef CHIP 

02810 error "In <minix/config.h> piease define MACHÍAS' to have a legal valué" 

02811 tendif 

02812 

02813 # i f (MACHAS’ =^--S;) 

02814 error "MACHINE has incorrect valué (0)" 

02815 (¡enci f 

02816 

02817 #endif /* CONFIG H */ 
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02900 /* derechos reservados © por Prentice-Hall. Inc. Se concede permiso para 
02901 * redistribuir los programas binarios y fuente de este sistema para fines 
02902 * educativos o de investigación. Para otro uso se requiere permiso por 
02903 * escrito de Prentice-Hall. 

02904 */ 

02905 

02906 #define EXTERN extern /* empleado en archivos *.h */ 

02907 #define PRÍVATE static /* PRÍVATE x es el límite de escape de x */ 

02908 #de-fine PUBLIC /* PUBLIC es lo opuesto de PRÍVATE */ 

02909 #defíne FORWARD static /* algunos compil. requieren que sea 'static'* 

02910 

02911 #define TRUE 1 /* sirve para convertir enteros en booleanos * 

02912 #define FALSE 0 /* sirve para convertir enteros en üooleanos * 

02913 

02914 #defíne HZ 60 /* frec. reloj (ajustable por sof. en IBM-PC * 

02915 #defíne BLOCK A SIZE 1024 /* núm. bytes en un bloque de disco */ 

02916 #de-fine SUPERUSER (uidt) 0 /* uidt de superusuario */ 

02917 

02918 #defíne MAJOR 8 /* disp. princ. = (dev»MAJOR) & 0377 */ 

02919 #defíne MI ÑOR 0 /* disp. secund. = (dev»MINOR) & 0377 */ 

02920 

02921 #defíne NULL ((void *)0) /* apuntador nulo */ 

02922 #define CPVECNR 16 /* máx. entradas en solicitud SYS VCOPY */ 

02923 #define NRIOREQS MIN(NR BUFS, 64) 

02924 /* máx. entradas en solicitud de E/S */ 

02925 

02926 #defíne NR SEGS 3 /* núm. segmentos por proceso */ 

02927 #define T 0 /* proc[i].memmap[T] es p/texto */ 

02928 #define D 1 /* proc[i],memmap[D] es p/datos */ 

02929 #defíne S 2 1* proc[i] ,menimap[S] es p/pila */ 

02930 

02931 /* Núms. de proceso de algunos procesos importantes. */ 

02932 #define MM PROC NR 0 /* núm. proc. del adm. de memoria */ 

02933 #define FS PROC NR 1 /* núm. proc. del sist. de aren. */ 

02934 #defíne INET PROC_NR 2 /* núm. proc. del servidor TCP/IP */ 

02935 ffdefine INIT PROC_NR (INET PROGNR + ENABLENETWORKING) 

02936 /* init — el proceso para mu Itius Liarlo */ 

02937 #define LOWJJSER (INET PROCNR + ENABLENETWORKING) 

02938 /* 1er. usuario no es parte del sist. op. */ 

02939 

02940 /* Diversos */ 

02941 #defíne BYTE 0377 /* máscara para 8 bits */ 

02942 #define READING 0 /* copiar datos en usuario */ 

02943 #define WRITING 1 /* copiar datos de usuario */ 

02944 #defíne NO NUM 0x8000 /" argumento numérico para panic() */ 

02945 #defíne NIL PTR (char *) ó /* expr. de utilidad general */ 

02946 #define HAVESCATTEREDIO 1 /* E/S dispersa ahora es estándar */ 

02947 

02948 /* Macr-os. */ 

02949 #defíne MAX(a, b) ((a) > (b) ? (a): (b)) 

02950 #defíne MIN(a, b) ((a) < (b) ? (a): (b)) 

02951 

02952 /* Número de tareas, */ 

02953 #define NRTASKS (9 + ENABLEWINI + ENABLESCSI + ENABLECDROM \ 
02954 + ENABLENETWORKING + 2 * ENABLEAUDIO) 
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02955 

02956 

02957 

02958 

02959 

02960 

02961 

02962 

02963 

02964 

02965 

02966 

02967 

02968 

02969 

02970 

\02971 

02972 

i 02973 

102974 

02975 

/02976 

02977 

02978 

02979 

02980 

02981 

02982 

02983 

02984 

02985 

02986 

02987 

02988 

02989 

02990 

02991 

02992 

02993 

02994 

02995 

02996 

02997 

02998 

02999 

03000 

03001 

03002 


/* La memoria se asigna en clics. */ 

#if fCHIP == INTEL) 

#define CLICK SIZE 256 /" unidad de asignación de memoria */ 

#define CLICK SHIFT 8 /* log2 de GLICK SIZE */ 

#endif 

#if (CHIP = SPARC) ¡; (CHIP = M68000) 

#define CLICK SIZE 4096 /* unidad de asignación de memoria */ 

#defíne CLICK SHIFT 12 /* 21og de CLICK SIZE */ 

#endif 

#define clicl<toroundk(n) \ 

((unsigned) ((((unsigned long) (n) « CLIGK SHIFT) + 512) / 1024)) 
#if CLIGK SIZE < 1024 
#define kJtoclick(n) ((n) * (1024 / CLICKSIZE)) 
ffelse 

ffdefine ktoclick(n) ((n) / (CLICK SIZE /1024)) 

#endif 


#define ABS -999 /* este proc. implica memoria absoluta */ 


/* Bits de bandera para imode en el nodo-i. */ 
#defíne ITYPE 0170000 

#define IRREGULAR 0100000 

#defíne IBLOCKSPECIAL 0060000 

#defíne IDIRECTORY 0040000 

#defíne ICHARSPECIAL 0020000 

#define INAMEDPIPE 0010000 

#defíne ISETUIDBIT 0004000 

#defíne ISETGIDBIT 0002000 

#defíne ALL MODES 0006777 

#defíne RWXMODES 0000777 

#define RBIT 0000004 

#defíne WBIT 0000002 

#define XBIT 0080001 

#defíne INOTALLOC 0000000 


/* tipo de nodo-i */ 

/* arch. normal, no dir. ni especial */ 

/* archivo especial por bloques */ 

/* el arch. es un directorio */ 

/* arch. especial por caracteres */ 

/* conducto con nombre (FIFO) */ 

/* fijar uidt efectivo en exec */ 

/* fijar gidt efectivo en exec */ 

/* todos bits para usuario, grupo y otros */ 
/* bits de modo sólo para RWX */ 

/* bit de protección Rwx */ 

/* bit de protección rWx */ 

/* bit de protección rwX */ 

/* este nodo-i está libre *7 


/* Algunos limites. */ 
#define MAXBLOCK NR 
#define HIGHESTZONE 
#define MAX INODE NR 
#define MAXFILEPOS 


((block t) 077777777) /* núm. de bloque más grande * 
((zonet) 077777777) /* núm. de zona más grande */ 
((ino t) 0177777) /* núm. de nodo-i más grande */ 

((offt) 037777777777) /- máx. distancia de arch. legal */ 


ffdefine NOBLOCK 
#define NOENTRY 
#define NO ZONE 
#define NODEV 


((block t) 0) 
((inot) 0) 
((zonet) 0) 
((devt) 0) 


/* ausencia de núm. de bloque */ 
/* ausencia de entrada de dir. */ 

/* ausencia de núm. de zona */ 

/* ausencia de núm. disp. */ 
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include/minix/type .n 


03100 #iíndef TYPE H 
03101 #define TYPE H 
03102 #ilndef MINIX TYPE H 
03103 #define MINIXTYPEH 
03104 

03105 /* Definiciones de tipos. */ 

03106 typedef unsigned int virclicks; /* dir. virtuales y longitudes en clics */ 

03107 typedef unsigned long physbytes;/* dir. físicas y longitudes en bytes */ 

03108 typedef unsigned int pnysclicks;/* dir. físicas y longitudes en clics */ 

03109 

03110 #if (CHIP == INTEL) 

03111 typedef unsigned int vir üytes; /* dir. virtuales y longitudes en bytes */ 

03112 #endif 
03113 

03114 #if (CHIP == M68000) 

03115 typedef unsigned long virbytes;/* dir. virtuales y longitudes en bytes */ 

03116 #endif 
03117 

03118 #if (CHIP == SPARC) 

03119 typedef unsigned long vir bytes;/* dir. virtuales y longitudes en bytes •/ 

03120 #endif 
03121 

03122 /* Tipos relacionados con mensajes. *•/ 

03123 #defíne MI 1 

03124 #defíne M3 3 

03125 #defíne M4 4 

03126 #define M3STRING 14 
03127 

03128 typedef struct {int mlil, mli2, mli3; char *mlpl, *mlp2, *mlp3;} messl; 

03129 typedef struct {int m2il, m2i2, m2i3; long m2n , m212; char 'tm2pl;} meS52; 
03130 typedef struct {int tn3J.l, m3i2; cnar *m3pl; char m3cal [M3STRING];} mess3; 
03131 typedef struct {long m411, m412, ni413, m414, m415;} mess4; 

03132 typedef struct {char m5cl, m5c2; int in5il, m5i2; long m511, m512, ni513; }mess5 
03133 typedef struct {int mGil, m6i2, m6i3; long m611; sighandler't ni6fl;} mess6; 
03134 

03135 typedef struct { 

03136 int msource; /* quién envió el mensaje */ 

03137 int mtype; /* qué clase de mensaje es */ 

03138 unión { 

03139 messlmml; 

03140 mess_2_mm2; 

03141 mess_3_ mm3; 

03142 mess_4_mm4; 

03143 fness_5_ mm5; 

03144 mess_6_mm6; 

03145 } m u; 

03146 } message, 

03147 

03148 /* Los siguientes define proporcionan nombres de miembros útiles. */ 

03149 #defíne ml il mu.mml .mlil 
03150 #defíne ml_i2 m_u.m_ml.mli2 
03151 #defíne mli_3 m_u.m_ml.mli3 
03152 #defineml_pl m u.m ml.mlpl 
03153 #define ml_p2 m u.m ml ,mlp2 
03154 #defíne ml_p3 m_u,m_ml,mlp3 
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03155 

03156 #defme m2_il m_u.m_m2 -m2i 1 
03157 #define m2_i2 m_u.m_m2.m2i2 
03158 #define m2_i3 m_u.m_m2,m2i3 
03159 #define m2_l 1 m_u.m_m2.m2il 
03160 #define m2_12 m_u.m_m2 ,m2i2 
03161 #define m2_pl m_u.m_m2 ,m2p 1 
03162 

03163 #define m3_il m_u.m_m3.m3il 
03164 #define m3_i2 m_u.m_m3 ,m3i2 
03165 #define m3_pl m_u.m_m3 ,m3p 1 
03166 #define m3_cal m_u.m_m3.m3cal 
03167 

03168 #define m4_ll m_u.m_m4.m411 
03169 #define ni4_12 m_u.m_m4.m412 
03170 #defíne m4_13 m_u.m_m4.m413 
03171 #de-fine m4_14 m_u.m_m4.m414 
03172 #define m4_15 m_u.m_m4.m415 
03173 

03174 ffdefíne m5_c 1 m_u.m_m5 ,m5c 1 
03175 ffdefíne m5_c2 m_u.m_m5.m5c2 
03176 #define m5_il m_u.m_m5.m5il 
03177 #defíne in5_i2 m u . m_m5.m5i2 
03178 #define m5_ll m_u.m_m5.m511 
03179 #defíne m5_12 m_u.m_m5.m512 
03180 #defíne m5_13 m_u.m_m5.m513 
03181 

03182 #define m6_i 1 m_u.m_m6 .m6i 1 
03183 #define m6_i2 m_u.m_m6 ,m6i2 
03184 #define m6_i3 m_u.m_m6.m6i3 
03185 ffdefíne m_611 m_u.m_m6.m6il 
03186 #define m_6fl m_u.m_m6.m6fl 
03187 

03188 structmemmap { 

03189 virclicks memvir; /* dirección virtual */ 

03190 physclicks memphys; /* dirección física */ 

03191 vir clicks mem len; /* longitud */ 

03192 }; 

03193 

03194 struct iorequests { 

03195 long ioposition; /* pos. en aren, de disp. (realmente offt) */ 

03196 char *iobuf; /* buffer en espacio de usuario */ 

03197 intionbytes; /* tamaño de solicitud */ 

03198 unsigned short io request; /* leer, escribir (opcionalmente) */ 

03199 }; 

03200 ffendif /* TYPEH */ 

03201 

03202 typedef struct { 

03203 virbytes iovaddr; /* dirección de un buffer de E/s */ 

03204 virbytes iovsize; /* tamaño de un buffer de E/S */ 

03205 } iovec t; 

03206 

03207 «typedef struct { 

03208 virbytes cpvsrc; /* dirección origen de datos */ 

03209 virbytes cpv A dst; /* dirección destino de datos */ 

03210 virbytes cpv A size; /* tamaño de datos */ 

03211 } cpvect; 

03212 

03213 /* MM pasa la dirección de una estructure de este tipo a KERNEL cuando se invoca 
03214 * dosendsig() como parte del mecanismo para atrapar señales. 
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03215 * La estructura contiene toda 

03216 * la pila de señales. 

03217 */ 

03218 struct sigmsg { 

03219 int sm signo; 

03220 unsigned long sm mask; 

03221 vir bytes sni sighandler 

03222 vir\_bytes sm sigretum; 

03223 vir bytes sm stkptr; 

03224 }; 

03225 

03226 #defíne MESS SIZE (sizeof(message)) /* podría necesitar usizeof de fs aquí */ 
03227 #defíne NIL MESS ((message *) 0) 

03228 

03229 struct psinfo { /* información para el programa ps(l) */ 

03230 ul6_t nrtasks, nr_procs; /* constantes NRTASKS y NR PROCS. */ 

03231 vir bytes proc, mproc, fproc; /* dir. de las tablas de proc. princ. */ 

03232 }; 

03233 

03234 #endif /* MINIX TYPE H */ 


la información que KERMEL necesita para construir 


/* núm. de señal que se añapa */ 

/* máscara para restaurar al regresar •*/ 
/* dirección del manejador */ 

/* dir. de sigretum en biblioteca C */ 

/* apuntador a pila de usuario */ 


include/minix/ sysiib.h 


03300 /* Prototipos de funciones de la biblioteca del sistema. */ 

03301 

03302 #ifndef SYSLIB H 
03303 #define _SYSLIB_H 
03304 

03305 /* Ocultar nombres para no contaminar espacio de nombres. */ 

03306 #defme sendrec sendrec 

03307 #defme receive receive 

03308 #define send send 

03309 

03310 /* Biblioteca de usuario+sistema de Minix. */ 

03311 _PROTOTYPE( void printk, (char *_fmt,...) ); 

03312 _PROTOTYPE( int sendrec, (int src dest, message *_m_ptr~) ); 

03313 _PROTOTYPE( int taskcall, (int _who, int syscallnr, message *_tnsgptr)); 
03314 

03315 /* Biblioteca de sistema de Minix. */ 

03316 _PROTOTYPE( mt receive, (int _src, message *_m_ptr) ); 

03317 _PROTOTYPE( int send, (mt dest, message '*_m_ptr-) ); 

03318 

03319 PROTOTYPE( int sys_abort, (int _how,...) ); 

03320 _PROTOTYPE( int sys adjmap, (int _pi~oc, struct mem map *_ptr, 

03321 vir' clicks data clicks, vir clicks _sp) ); 

03322 _PROTOTYPE( int sys copy, (int _sr-c_proc, mt src seg, pnys bytes src vir, 
03323 int _dst_proc, int dst seg, phys bytes dst vir, phyc bytes bytes)); 

03324 _PROTOTYPE( int sys exec, (int _proc, char *_ptr, int traced, 

03325 char *_aout, vir bytes initpc) ); 

03326 _PROTOTYPE( int sys execmap, (int _proc, struct mem map *_ptr) ); 
03327 _PROTOTYPE( int sys A fork, (int _parent, int child, int _pid, 

03328 phys clicks shadow) ); 

03329 _PROTOTYPE( int sys ffesh, (int _proc, struct mem A map *_ptr, 
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03330 physclicks *_basep, physclicks *_sizep) ); 

03331 _PROTOTYPE( in-t sys getsp, (int _proc, vir bytes *_newsp) ); 

03332 _PROTOTYPE( int sysnewmap, (int _proc, struct memmap *_ptr) ); 

03333 _PROTOTYPE( int sys getmap, (int _proc, struct mem map *_ptr) ); 

03334 _PROTOTYPE( mt syssendsig (mt _proc, str-uct sigmsg *_ptr) ); 


03335 _PROTOTYPE( int sysoldsig, (int _proc, int _sig, sighandler t sighandler)); 

03336 _PROTOTYPE( int sysendsig, (mt _proc) ); 

03337 _PROTOTYPE( int syssigretu , (int _proc, vir bytes _scp, int _flags) ); 

03338 _PROTOTYPE( int systrace, (mt _req, int _procnr, long addr, long "_data_p)); 
03339 _PROTOTYPE( int sys xit, (int _parent, int _pr'oc, phys clicks *_basep, 

03340 phys clicks *_sizep)); 

03341 _PROTOTYPE( int syskill, (int _proc, int _sig) ); 

03342 _PROTOTYPE( int systimes, (int _proc, clock t _ptr[5]) ); 

03343 

03344 #endif /* SYSLIBH */ 


include/minix/calinr.h 


03400 #defíne NCALLS 
03401 

03402 #defíne EXIT 
03403 #defíne FORK 
03404 #defíne READ 
03405 #defíne WRITE 
03406 #defíne OPEN 
03407 ffdefíne GLOSE 
03408 #defíne WAIT 
03409 ffde-fineCREAT 
03410 #defíne LINK 
03411 #defíne UNLINK 
03412 #defíne WAITPID 
03413 #defíne CHDIR 
03414 #defíne TIME 
03415 #defíne MKNOD 
03416 #defíne CHMOD 
03417 #defíne CHOWN 
03418 ffdefíne BRK 
03419 #defíne STAT 
03420 #defíne LSEEK 
03421 #defíne GETPID 
03422 #defíne MOUNT 
03423 ffdefíne UMOUNT 
03424 #de-fme SETUID 
03425 #defíne GETUID 
03426 ffdefíne STIME 
03427 #defme PTRACE 
03428 ffde-fineALARM 
03429 #defíne FSTAT 
03430 #defíne PAUSE 
03431 #defíne UTIME 
03432 ffdefíne ACCESS 
03433 #defíne SYNC 
03434 #defíne KILL 


77 /* núm. De llamadas al sist. Permitidas */ 


2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 
33 

36 

37 
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03435 

03436 

03437 

03438 

03439 

03440 

03441 

03442 

03443 

03444 

03445 

03446 

03447 

03448 

03449 

03450 

03451 

03452 

03453 

03454 

03455 

03456 

03457 

03458 

03459 

03460 

03461 

03462 

03463 

03464 

03465 


#define RÉNAME 38 

#defme MKDIR 39 

#defme RMDIR 40 

#defme DUP 41 

#defme PIPE 42 

#defme TIMES 43 

#define SETGID 46 

#define GETGID 47 

#define SIGNAL 48 

#defme IOCTL 54 

#defme FCNTL 55 

#defme EXEC 59 

#define UMASK 60 

#define CHROOT 61 

#defme SETSID 62 

#define GETPGRP 63 


/* Las siguientes no son llamadas al sistema, pero se procesan como tales*/ 


#define KSIG 
#define UN PAUSE 
#define REVIVE 
#define TASKJ1EPLY 


/* ker-nel detectó una señal */ 
a MM o FS; comprobar EINTR */ 
a FS: revivir proceso dormido */ 
a FS: código de respuesta de tarea tty */ 


/* Posix signal handiing. */ 
#define SIGACTION 71 

#define SIGSUSPEND 72 

#define SIQPENDING 73 

#define SIGPROGMASK 74 

#define SIGRETURN 75 


#defíne REBOOT 76 


include/minix/ com.h 


03500 /* llamadas al sistema, pero se procesan como tales. */ 

03501 #define SEND 1 /* cód. lime, para enviar mensajes */ 

03502 # define RECEIVE 2 /* cód. fuñe, para recibir mensajes */ 

03503 #define BOTH 3 /* cód. fuñe, para SEND + RECEIVE */ 

03504 #defineANY (NR PROCS+100) /* receive (ANY, buf) acepta de cualq. origen */ 

03505 

03506 /* Números de tarea, códigos de función y códigos de respuesta. */ 

03507 

03508 /* Los valores de varios núms. de tarea dependen de si están habilitadas 

03509 * ellas u otras tareas. Se definen como (PREVIOUS TASK - ENABLETASK) en general, 

03510 * ENABLE TASK es 0 o 1, asi que una tarea recibe un núm. nuevo o bien el 

03511 * mismo de la tarea anterior y ya no se usa más. 

03512 * La tarea TTY siempre debe tener el núm. más negativo para inicializarse 
03513 * primero. Muchos códigos de función TTY se comparten con otras 
03514 * tareas. 

03515 */ 

03516 

03517 #define TTY (DL ETH -1) 

03518 /* clase de E/S de terminal */ 

03519 # define CANCEL 0 /* req general para que una tarea cancele */ 
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03520 # define HARDINT 2 /* código fcn p/todas interrup. de hard . */ 

03521 # define DEVREAD 3 /* código fcn p/leer de tty */ 

03522 # define DEVWRITE 4 /* código fcn p/escribir en tty */ 

03523 # define DEV IOCTL 5 /* código fcn p/iocti */ 

03524 # define DEV OPEN 6 /* código fcn p/abrir tty */ 

03525 # define DEVGLOSE 7 /* código fcn p/cerrar tty */ 

03526 # define SCATTERED IO 8 /* código fcn p/múlt. lect./escrit. */ 

03527 # define TTY SETPGRP 9 /* código fcn p/setpgroup */ 

03528 # define TTY EXIT 10 /* un jefe de grupo de proc. salió */ 

03529 # define OPTIONAL IO 16 /* modificador-de códigos DEV* en vector "/ 

03530 # define SUSPEND -998 /* se usa en interrup. si tty no tiene datos */ 

03531 

03532 #define DLETH (CDROM - ENABLENETWORKING) 

03533 /* tarea en red */ 

03534 

03535 /* Tipo de mensaje para solicitudes de capa de enlace de datos. */ 

03536 # define DL WRITE 3 

03537 ff define DLWRITEV 4 

03538 # define DLREAD 5 

03539 # define DLREADV 6 

03540 # define DL INIT 7 

03541 # define DLSTOP 8 

03542 # define DLGETSTAT 9 

03543 

03544 I* Tipo de mensaje para respuestas de capa de enlace de datos. */ 

03545 # define DL INIT REPLY 20 

03546 # define DLTASKREPLY 21 

03547 

03548 # define DLPORT m2_il 

03549 # define DLPROC m2_i2 

03550 # define DLCOUNT m2_i3 

03551 # define DLMODE m2_ll 

03552 # define DLCLCK m2_12 

03553 # define DLADDR m2_pl 

03554 # define DLSTAT m_2,ll 

03555 

03556 /* Bits de campo 'DL STAT' de respuestas de DL. */ 

03557 # define DL PACK SEND 0X01 

03558 # define DL PACKRECV 0x02 

03559 # define DLREADIP 0x04 

03560 

03561 /* Bits de campo 'DL MODE' de solicitudes de DL. */ 

03562 # define DLNOMODE 0x0 

03563 # define DL PROMISC REQ 0x2 

03564 # define DL_ MULTI REQ 0x4 

03565 # define DLBROADREQ 0x8 

03566 

03567 # define NW_OPEN DEV_OPEN 

03568 # define NW_CLOSE DEVGLOSE 

03569 # define NW_READ DEVAREAD 

03570 # define NW_WRITE DEVWRITE 

03571 # define NWJOCTL DEVJOCTL 

03572 # define NW_CANCEL CANCEL 

03573 

03574 #define CDROM (AUDIO - ENABLECDROM) 

03575 /* tarea de dispositivo CD-ROM */ 

03576 

03577 #define AUDIO (MIXER-ENABLE AUDIO) 

03578 #define MIXER (SCSI - ENABLEAUDIO) 

03579 /* tareas de disp. de audio y mezclador */ 
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03580 

03581 

03582 

03583 

03584 

03585 

03586 

03587 

03588 

03589 

03590 

03591 

03592 

03593 

03594 

03595 

03596 

03597 

03598 

03599 

03600 

03601 

03602 

03603 

03604 

03605 

03606 

03607 

03608 

03609 

03610 

03611 

03612 

03613 

03614 

03615 

03616 

03617 

03618 

03619 

03620 

03621 

03622 

03623 

03624 

03625 

03626 

03627 

03628 

03629 

03630 

03631 

03632 

03633 

03634 

03635 

03636 

03637 

03638 

03639 
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#defme SCSI (WINCHESTER - ENABLE SCSI) 

/* tarea de dispositivo SCSI */ 

#define WINCHESTER (SYNALARMTASK - ENABLEWINI) 

/* clase de disco duro Winchester */ 

#define SYN ALARM TASK -8 /* tarea p/enviar mensajes CLOCKINT */ 

#define IDLE -7 /* tarea p/ejecutar si no hay qué ejecutar •'/ 

#define PRINTER -6 /* clase de E/S de impresora */ 

#define FLOPPY -5 /* clase de disco flexible */ 


#define MEM -4 

# define NULLMAJOR 1 

# define RAMDEV 0 

# define MEMDEV 1 

# define KMEMDEV 2 

# define NULLDEV 3 


clase /dev/ram, /dev/(k)mem y /dev/null */ 

disp. princ. para /dev/null 7 

disp. secund. para /dev/ram */ 

disp. secund. para /dev/mem */ 

disp. secund. para /dev/kmem */ 

disp. secund. para /dev/null */ 


#define CLOCK -3 

# define SETALARM 1 

# define GETTIME 3 

# define SETTIME 4 

# define GETUPTIME 5 

# define SET SYNC AL 6 


clase de reloj */ 

código fcn a CLOCK, fijar alarma */ 
código fcn a CLOCK, obt- tiempo real */ 
código fcn a CLOCK, fij. tiempo real */ 
código fcn a CLOCK, obt. tiempo activo : 
código fcn a CLOCK, fijar alarma que */ 


define REAL TIME 1 /* resp. de CLOCK: aqui está tiempo real */ 

define CLOCKINT HARDINT 

/* este código sólo será enviado por */ 

/* SYNLARMTASK a una tarea que */ 

/* solicitó una alarma síncrona */ 


#define SYSTASK -2 /* funciones internas */ 

# define SYS XIT 1 /* código fcn para sys_xit(parent, proc) */ 

# define SYS GETSP 2 /* código fcn para sys_sp(proc, &new_sp) */ 

# define SYS OLDSIG 3 /* código fcn para sys_oldisig(proc, sig) */ 

# define SYS FORK 4 /* código fcn para sys_fork(parent, child) */ 

# define SVS NEWMAP 5 /* código fcn para sys_newmap(procno, map_ptr)*/ 

# define SYS COPY 6 /* código fcn para sys copy(ptr) */ 

# define SYS EXEC 7 /* código fcn para sys_exec(procno, new sp) */ 

# define SYS TIMES 8 /* código fcn para sys_times(procno, bufptr) */ 

# define SYS ABORT 9 /* código fcn para sys_abort() */ 

# define SYS FRESH 10 /* código fcn para sys_fresn() (sólo Atari) */ 

# define SYS KILL 11 /* código fcn para sys_kill(proc, sig) */ 

# define SYS GBOOT 12 /* código fcn para sys_gboot(procno, bootptr) */ 

# define SYS UMAP 13 /* código fcn para sys_umap(procno, etc) */ 

# define SYS MEM 14 /* código fcn para sy5_mem() */ 

# define SYS TRACE 15 /* código fcn para sys_trace(req, pid, addr, data) */ 

# define SYS_VCOPY 16 /* código fcn para sys vcopy(src_proc, dest_proc, vcopy_s, 

vcopy_ptr) */ 

# define SYS SENDSIG 17 /* código fcn para sys_sendsig(&aigmsg) */ 

# define SYS SIGRETURN 18 /* código fcn para sys_sigretum(&sigmsg) */ 

# define SYS ENDSIG 19 /* código fcn para sys_endsig(procno) */ 

# define SYS GETMAP 20 /*código fcn para sys_getmap(procno, map_ptr) */ 

#define HARDWARE -1 /* origen en mensajes gen. por interrp. */ 
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03640 

/* Nombres de campos 

de mensaje para 

mensajes a la tarea CLOCK. */ 

03641 

#defíne DELTA TICKS 

m6 11 /* 

intervalo de alarma en tics */ 

03642 

#define FUNC TO CALI 

. m6_fl /* 

apunta a la función por llamar */ 

03643 

#define NEW TIME 

m6_l 1 /* 

valor p/poner reloj (SETTIME) */ 

03644 

#define CLOCKPROCNR m6_il /* 

¿qué pr-oc (o tarea) quiere alarma? */ 

03645 

#define SECONDSLEFT 

m6_ll /* 

¿cuántos segundos quedaban? */ 

03646 

03647 

/* Campos de mensaje 

para mensajes 

a tareas por bloques y caracteres. */ 

03648 

#defme DEVICE 

m2 il /* 

dispositivo princ./secund. */ 

03649 

#define PROC NR 

m2 i2 /* 

¿Qué proc. quiere E/S? */ 

03650 

#define COUNT 

m2 i3 /* 

núm. bytes por transferir */ 

03651 

#define REQUEST 

m2 i3 /* 

código de solicitud iocti */ 

03652 

#define POSITION 

m2_l 1 /* 

distancia en el archivo */ 

03653 

#defme ADDRESS 

m2_pl /* 

dirección de buffer central */ 

03654 

03655 

/* Nombres de campos 

de mensaje para 

mensajes a la tarea TTY. */ 

03656 

#define TTY LINE 

DEVICE /* 

parám. de mensaje: linea de terminal */ 

03657 

#define TTYREQUEST 

COUNT /* 

parám. de mensaje: cód. solicitud iocti */ 

03658 

#define TTYSPEK 

POSITION /* 

parám. de mensaje: rapidez iocti, borrado */ 

03659 

#define TTY FLAQS 

m2 12 /* 

parám. de mensaje: modo tty iocti 7 

03660 

#define TTYPGRP 

m2_i3 / * 

parám. de mensaje: gpo. de procesos */ 

03661 

03662 

/* Campos de mensaje 

para respuest 

a de situac. QIC 02 de controlador de cinta */ 

03663 

#define TAPE STAT0 

m2 11 


03664 

#define TAPESTAT1 

m2_12 


03665 

03666 

/* Campos de mensaje 

empleados en 

mensajes de respuesta de tareas. */ 

03667 

#define REP PROC NR 

m2 il /* 

# de proc. por los que se hizo E/S "/ 

03668 

#define REPSTATUS 

m2_i2 /* 

bytes transferidos o núm. de error */ 

03669 

03670 

/* Nombres de campos 

para mensaje 

de copia a SYSTASK. */ 

03671 

#define SRCSPACE 

m5_cl /* 

espacio T o D (la pila es D) */ 

03672 

#define SRC PROC NR 

m5 il /* 

proceso del cual copiar */ 

03673 

#define SRC BUFFER 

m5_ll /* 

dir. virtual de donde vienen datos */ 

03674 

#define DST SPACE 

m5 c2 /* 

espacio T o D (la pila es D) */ 

03675 

#define DST PROC NR 

m5 i2 /* 

proceso al cual copiar */ 

03676 

#define DSTBUFFER 

m5 12 /* 

dir. virtual adonde van los datos */ 

03677 

#define COPYBYTES 

m5 13 /* 

núm. de bytes por copiar */ 

03678 

03679 

/* Nombres de campos 

para contabilidad, SYSTASK y diversos. */ 

03680 

#define USER TIME 

m4 11 /* 

tiempo de usuario consumido por proc. */ 

03681 

#define SYSTEM TIME 

m4 12 /* 

tiempo de sistema consumido por proc. */ 

03682 

#define CHILD UTIME 

m4 13 /* 

tiempo usuario consum. por hijos del proc. */ 

03683 

#define CHILD STIME 

m4 14 /* 

tiempo sist. consum. por hijos del proc. */ 

03684 

#define BOOTTICKS 

m4_15 /* 

tics de reloj desde el arranque */ 

03685 

03686 

#define PROC1 

mi il /* 

indica un proceso */ 

03687 

#define PROC2 

mi i2 /* 

indica un proceso */ 

03688 

#define PID 

ml_i3 /* 

id de proceso pasado de MM a kemel */ 

03689 

#define STACK PTR 

ml_pl /* 

para apunt. a pila en sysexec, sysgetsp */ 

03690 

#defíne PR 

m6_il /* 

núm. de proc. para syssig */ 

03691 

#define SIGNUU 

m6_i2 / * 

núm. de señal para syssig */ 

03692 

#define FUNC 

m6 f 1 /* 

apunt. a función para syssig */ 

03693 

#define MEMPTR 

ml_pl /* 

dónde está mapa de memoria para sysnewmap */ 

03694 

#define NAMEPTR 

ml_p2 /* 

dónde está nombre de prog. para dmp */ 

03695 

#define IP PTR 

ml_p3 /* 

valor inicial de ip después de exec 7 

03696 

#define SIG PROC 

m2 il /" 

núm. de proc. para inform */ 

03697 

#define SIG MAP 

m2 11 /* 

lo usa kemel p/pasar mapa de bits de señal */ 

03698 

#define SIGMSGPTR 

mlil /* 

apunt. a info. p/crear pila p/atrap. señales */ 

03699 

#define SIQCTXTPTR 

ml_pl /* 

apunt. a info. p/restaurar contexto señal */ 
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inciude/minix/boot .h 


03700 

03701 

03702 

03703 

03704 

03705 

03706 

03707 

03708 

03709 

03710 

03711 

03712 

03713 

03714 

03715 

03716 

03717 

03718 

03719 

03720 

03721 

03722 

03723 

03724 

03725 

03726 

03727 

03728 

03729 


/* booth *•/ 

#ifndef BOOT H 
#define BOOTH 


/* Redefinir ios dispositivos raíz e imagen de raiz como variables 
" Esto reduce las diferencias pero puede causar confusión futura. 

*/ 

#define ROOT A DEV (bootpar'ameters .bprootdev) 

#define IMAGEDEV (bootparanieters .bpramimagedev) 


/* Números de dispositivo de discos RAM, fexible y duro. 

* h/com.h define RAM/DEV pero sólo como número secundario. 

*/ 

#defíne DEV FD0 0x200 
#define DEVHD0 0x300 
#defíne DEVRAM 0x100 
#defíne DEVSCSI 0x700 /* sólo Atari TT */ 


/* Estructura para contener parámetros de arranque. */ 
struct bparam s 
{ 

devt bprootdev; 
dev A t bpraininiagedev; 
unsigned short bprainsize; 
unsigned snort bp processor; 

}; 


extern struct bpar-am s boot parameters; 
#endif /* BOOTH */ 


inelude/minix/keymap. h 


03800 /* keymap .h - define mapa 


03801 

03802 

*/ 

#ifhdef 

SYS 

KEYMAP H 

03803 

#define 

SYS 

KEYMAPH 

03804 

03805 

#define 

C(c) 

((c) & 0X1F) 

03806 

#define 

A(c) 

((c) ¡ 0X80) 

03807 

#define 

CA(C) 

A(C(c)) 

03808 

#define 

L(c) 

((c): HASCAPS) 

03809 

03810 

#define 

EXT 

0X0100 

03811 

#define 

CTRL 

0X0200 

03812 

#define 

SHIFT 

0X0400 

03813 

#define 

ALT 

0x0800 


03814 #define EXTKEY 0X1000 


Autor: Marcus Hampel 


/* Mapear a código de control */ 

/* Activar- bit 8 (ALT) */ 

/* Control-AIt */ 

/* Agregar atrib. "Bloq. Mayús. activo" */ 

/* Teclas de fuñe. Normales */ 

/* Tecla control */ 

/* Tecla shift */ 

/* Tecla alt */ 

/* código de tecla extendido */ 
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/* Bloq. Mayús- activi 


83815 #define HASGAPS 0x8000 

83816 

03817 /* Subteclado numérico */ 

03818 #defme HOME (0x01+EXT) 

03819 #defme END (0x02 + EXT) 

03820 #defme UP (0x03 + EXT) 

03821 #define DOWN (0x04 +EXT) 

03822 #define LEFT (0x05 + EXT) 

03823 #defme RIGHT (0x06 + EXT) 

03824 #defme PGUP (0x07 + EXT) 

03825 #defme PGDN (0x08 + EXT) 

03826 #defme MID (0x09 + EXT) 

03827 #defme NMIN (OxOA + EXT) 

03828 #define PLUS (OxOB + EXT) 

03829 #defme INSRT (OxOG + EXT) 

03830 

03831 /* Alt + Subteclado numérico 

03832 #define AHOME (0x01 + ALT) 

03833 #define AEND (0x02+ALT) 

03834 #define AUP (0x03+ALT) 

03835 #define ADOWN (0x04 + ALT) 

03836 #define ALEFT (0x05+ALT) 

03837 #defíne ARIGHT (0x06 + ALT) 

03838 #define APGUP (0x07+ALT) 

03839 #define APGDN (0x08 + ALT) 

03840 #define AMID (0x09 +ALT) 

03841 #define ANMIN (OxOA + ALT) 

03842 #defíne AFLÚS (OxOB + ALT) 

03843 #defíne AINSRT (OxOC + ALT) 

03844 

03845 /* Ctri + Subteclado numérico 
03846 #defíne CHOME (0x01 + CTRL) 

03847 #defíne CEND (0x02 + GTRL) 

03848 #defíne CUP (0x03 + CTRL) 

03849 #defíne CDOWN (0x04 + CTRL) 

03850 #define CLEFT (0x05+CTRL) 

03851 #defíne CRIGHT (0x06 + CTRL) 

03852 #define CPGUP (0x07 +CTRL) 

03853 #define CPGDN (0x08 + CTRL) 

03854 #define CMID (0x09 +CTRL) 

03855 #define CNMIN (OxOA + CTRL) 

03856 #define CPLUS (OxOB + CTRL) 

03857 #define CINSRT (OxOC + CTRL) 

03858 

03859 /* Teclas locales */ 

03860 #define CALOCK (OxOD + EXT) /* bloq. mayús. */ 

03861 #defme NLOCK (BxOE + EXT) /* bloq. núm. */ 

03862 #defíne SLOCK (OxOF + EXT) /* bloq. despl. */ 

03863 

03864 /* Teclas de función */ 

03865 #define F1 (0x10 +EXT) 

03866 #define F2 (0x11+EXT) 

03867 #define F3 (0x12 +EXT) 

03868 #define F4 (0x13 +EXT) 

03869 #define F5 (0x14 + EXT) 

03870 #define F6 (0x15 +EXT) 

03871 #de-fine F7 (0x16 +EXT) 

03872 #define F8 (0x17 +EXT) 

03873 #define F9 (0x18 +EXT) 

03874 #define FIO (0x19+ EXÍ) 
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03875 #define Fll 
03876 #define F12 
03877 

03878 /* Alt+Fn */ 
03879 #defme AF1 
03880 #define AF2 
03881 #defme AF3 
03882 #defme AF4 
03883 #defme AF5 
03884 #defme AF6 
03885 #defme AF7 
03886 #defme AF8 
03887 #defme AF9 
03888 #defme AF10 
03889 #defme AF11 
03890 #defme AF12 
03891 

03892 /* Ctrl+Fn */ 
03893 #defme CF1 
03894 #defme CF2 
03895 #defme CF3 
03896 #defme GF4 
03897 #defme CF5 
03898 #defme CF6 
03899 #defme CF7 
03900 #defme CF8 
03901 #defme GF9 
03902 #defme CF10 
03903 #defme CF11 
03904 #defme CF12 
03905 

03906 /* Shift+Fn */ 
03907 #defme SF1 
03908 #defme SF2 
03909 #defme SF3 
03910 #defme SF4 
03911 #defme SF5 
03912 #defme SF6 
03913 #defme SF7 
03914 #defme SP8 
03915 #defme SF9 
03916 #defme SF10 
03917 #defme SF11 
03918 #defme SF12 
03919 

03920 /* Alt+Shift+Fn 
03921 #defme ASF1 
03922 #defme ASF2 
03923 #defme ASF3 
03924 #defme ASF4 
03925 #defme ASF5 
03926 #defme ASF6 
03927 #defme ASF7 
03928 #defme ASF8 
03929 #defme ASF9 
03930 #defme ASF10 
03931 #defme ASF11 
03932 #defme ASF12 
03933 

03934 #defme MAPC( 


(0X1A 

+ EXT) 

(0X1B 

+ EXT) 

(0x10 + 

ALT) 

(0x11 + 

ALT) 

(0X12 H 

-ALT) 

(0x13 + 

ALT) 

(0x14 + 

ALT) 

(0x15 + 

ALT) 

(0X16 H 

-ALT) 

(0X17 H 

-ALT) 

(0x18 + 

ALT) 

(0x19 + 

ALT) 

(0X1A 

+ ALT) 

(0X18 H 

-ALT) 

(0x10 + 

CTRL) 

(0X11 H 

- CTRL) 

(0X12 H 

- CTRL) 

(0x13 + 

CTRL) 

(0x14 + 

CTRL) 

(0x15 + 

CTRL) 

(0x16 + 

CTRL) 

(0X17 H 

- CTRL) 

(0x18 + 

CTRL) 

(0x19 + 

CTRL) 

(0X1A 

+ CTRL) 

(0X1B 

f CTRL) 

(0x10 + 

SHIFT) 

(0x11 + 

SHIFT) 

(0x12 + 

SHIFT) 

(0x13 + 

SHIFT) 

(0x14 + 

SHIFT) 

(0x15 + 

SHIFT) 

(0x16 + 

SHIFT) 

(0x17 + 

SHIFT) 

(0x18 + 

SHIFT) 

(0x19 + 

SHIFT) 

(0X1A 

+ SHIFT» 

(OxlB 4 

- SHIFT) 

*/ 

(0X10 H 

- ALT + SHIFT) 

(0x11 + 

ALT + SHIFT) 

(0x12 + 

ALT + SHIFT) 

(0x13 + 

ALT + SHIFT) 

(0x14 + 

ALT + SHIFT) 

(0x15 + 

ALT + SHIFT) 

(0x16 + 

ALT + SHIFT) 

(0x17 + 

ALT + SHIFT) 

(0x18 + 

ALT + SHIFT) 

(0x19 + 

ALT + SHIFT) 

(0X1A 

+ ALT + SHIFT) 

(OxlB 4 

- ALT + SHIFT) 


6 /* Núm. 


; cois, en mapa de teclas */ 
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03935 #define NR SCAN CODES 0x80 /* Núm. códigos detec. (füas en mapa) */ 
03936 

03937 typede-F unsigned short keymapttNRSCANCODES * MAP COLS]; 

03938 

03939 #define KEYJ1AGIC "KMAZ" /* número mágico del arch. de mapa de teclas */ 
03940 

03941 #endif /* _SYS KEYMAP_H */ 


include/minix/par-tition.h 

04000 

/* minix/partition.h 

Autor: Kees J. Bot 

04001 

* 

Dic. 7. 1995 

04002 

* Lugar de una partición en disco y la geometría de disco, 


04003 

* para usarse con los iocti DIOCGETP y DIOCSETP, 


04004 

*/ 


04005 

#ifndef MINIX PARTITION H 


04006 

#defíne UINIX PARTITIONH 


04007 



04008 

struct partition { 


04009 

u32_t base; /* distancia en bytes a inicio de partición */ 

04010 

u32_t size; /* número de bytes en la partición */ 


04011 

unsigned cylinders; /* geometría de disco */ 


04012 

unsigned heads; 


04013 

unsigned sectors; 


04014 

}; 


04015 

#endif /* MINIX PARTITION H */ 


include/ibm/partition.n 


04100 /* Descripción de una entrada de la tabla de particiones */ 
04101 #endif PARTITION H */ 

04102 #define PARTITION H */ 

04103 

04104 struct pact A ent ry { 


04105 

unsigned 

char 

bootind; 

/* 

04106 

unsigned 

char 

start A head; 

/* 

04107 

unsigned 

char 

star'tsec; 

/* 

04108 

unsigned 

char 

startcyl; 

/* 

04109 

unsigned 

char 

sysind; 

/* 

04110 

unsigned 

char 

last A head; 

/* 

04111 

unsigned 

char 

last A sec; 

/* 

04112 

unsigned 

char 

last A cyl; 

/* 

04113 

unsigned 

long 

lowsec; 

/* 

04114 

unsigned 

long 

size; 

/* 

04115 

04116 

04117 

}; 

#defíne ACTIVE FLAQ 

0x80 

/* 

04118 

#define NR 

PARTITIONS 4 

/* 


04119 #de-fine PART A TABLE A OFF 0x1 BE /* 


indicador de arranque Ó/AGTIVE A FEAG */ 

valor de cabeza p/primer sector */ 

valor sector + bits cil. p/ier. sector */ 

valor de pista p/ier. sector */ 

indicador de sistema */ 

valor de cabeza p/últ. sector */ 

val. sector + bits cil. p/últ. sector */ 

valor de pista p/últ. sector */ 

ler. sector lógico */ 

tamaño de partición en sectores */ 


valor de activo en campo bootind (hdO) */ 

# entradas en tabla de partic. */ 

dist. de tabla de partic. en sec. arranque */ 
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04120 /* Tipos de particiones. */ 

04121 #defme MINIX_PART 0x81 /* Tipo de partición Minix */ 

04122 #defme NO_PART 0x00 /* entrada no utilizada */ 

04123 #defíne OLD MINIX PART 0x80 /* creada antes de 1.4b, obsoleta */ 
04124 #defme EXTPART 0x05 /* partición extendida */ 

04125 

04126 

04127 #endif /* PARTITION H */ 


src/kemel/kemel.h 

04200 

/* Ésta es la cabecera 

maestra 

del 

kernel; incluye algunos otros archivos 

04201 

* y define las principales constantes. 



04202 

*/ 




04203 

#define POSIX SOURCE 

1 

/* 

decir a cabeceras que incluyan cosas POSIX */ 

04204 

#define MINIX 


1 /* 

decir a cabeceras que incluyan cosas UINIX */ 

04205 

#define SYSTEM 


1 

/* decir a cabeceras que éste es el kemel */ 

04206 





04207 

/* Lo siguiente es tan 

básico 

que 

todo archivo *.c lo obtiene automáticamente. */ 

04208 

#include <minix/con-Fig 

,h> 

/* 

DEBE ser primero */ 

04209 

#include <ansi.h> 


/* 

DEBE ser segundo */ 

04210 

ffinclude<sys/types.h> 




04211 

#include <minix/const.h> 




04212 

#include <minix/type.h> 




04213 

#include <minix/syslib.h> 




04214 





04215 

ffinclude<string.h> 




04216 

#include <limits.h> 




04217 

#include <err'no.h> 




04218 





04219 

#include "const.h" 




04220 

#include "type.h" 




04221 

#inciude "proto.h" 




04222 

#include "glo.h" 




src/kemel/const.h 


04300 /* Constantes generales empleadas por el kemel. */ 

04301 

04302 #if(CHIP = INTEL) 

04303 

04304 #defme KSTACKBYTES 1024 /* # bytes para la pila del kernel */ 

04305 

04306 #define INIT_PSW 0x0200 /* psw inicial */ 

04307 #defme IHIT TASK PSW 0x1200 /* psw inicial para tareas (con IOPL 1) */ 

04308 #defme TRACEBIT 0x100 /* OR esto con psw enproc[] p/rastreo */ 

04309 #define SETPSW(rp, new) /* sólo permite activar ciertos bits */ \ 

04310 ((rp)->p_reg.psw = (rp)->p_reg.psw & -0xCD5 ¡ (new) & 0xCD5) 

04311 

04312 /* Sp inicial para mm, fs e init. 

04313 * 2 bytes para salto corto 

04314 * 2 bytes no utilizados 
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04315 * 3 palabras para init_org[], sólo lo usa fs 

04316 * 3 palabras p/trampa de depurador en modo real (de hecho necesita 1 más) 

04317 * 3 palabras para guardar y reiniciar temporales 

04318 * 3 palabras para interrupción 

04319 * No dejar margen, para eliminar errores pronto. 

04320 */ 

04321 #defme INII_SP (2 + 2 + 3*2 + 3*2 + 3*2 + 3*2) 

04322 

04323 #defme HCLICK_SHIFT 4 /* 10g2 de HCLICKSIZE */ 

04324 #defme HCLICK SIZE 16 /* magia de conversión de seg. de hardware */ 

04325 #ifCLICK_SIZE>= HCLICKSIZE 

04326 #defme click_to_hclick(n) ((n) « (CLICKSHIFT -HCLICKSHIFT)) 

04327 #else 

04328 #defme click_to_hclick(n) ((n) » (HCLICK SHIFT -CLICK SHIFT)) 

04329 #endif 

04330 #defme hclick_to_physb(n) ((phys_bytes) (n) « HCLICK_SHIFT) 

04331 #defme physb_to_hclick(n) ((n) » HCLICK_SHIFT) 

04332 

04333 /* Vectores de interrupción definidos/reservados por el procesador. */ 

04334 #defme DIVIDE VECTOR 0 /* error de división */ 

04335 #defíne DEBUG VECTOR 1 /* paso a paso (rastreo) */ 

04336 #defme NMI_VECTOR 2 /* interrupción no enmascarable */ 

04337 #defme BREAKPOINTVECTOR 3 /* punto de corte en software */ 

04338#define OVERFLOW_VECTOR 4 /* de INTO */ 

04339 

04340 /* Vector de llamada al sistema fijo. */ 

04341 #define SYS VECTOR 32 /* llamadas se hacen con int SYSVEC */ 

04342 #define SYS386_VECTOR 33 /* excepto llamadas 386 usan esto */ 

04343 #define LEVEL0_VECTOR 34 /* para ejecutar una función en nivel 0 */ 

04344 

04345 /* Bases irq apropiadas para interrupciones por hardware. Reprogramar 8259(S) 

04346 * con predeterminados de PC BIOS ya que BIOS no respeta todos los vectores 

04347 * reservados por el procesador (0 a 31). 

04348 */ 

04349 #define BIOS_IROO_VEC 0x08/* base de vectores IROO-7 empleada por BIOS */ 

04350 #define BIOS_IR08_VEC 0x70/* base de vectores IR08-15 empleada por BIOS */ 

04351 #define IROOJVECTOR 0x28 /* +/- arbitrario pero> SYS_VECTOR */ 

04352 #define IRQ8_VECTOR 0x30 /* juntos por sencillez */ 

04353 

04354 /* Números de interrupciones de hardware. */ 

04355 #define NR_IRQ_VECTORS 16 

04356 #define CLOCK IRQ 0 

04357 #define KEYBOARD IRQ 1 

04358 #define CASCADE IRQ 2 /* hábil, cascada para 20. controlador AT */ 

04359 #define ETHER_IRQ 3 /* vector interrup. ethemet predeterm. */ 

04360 #define SECONDARY_IRQ 3 /* vector interrup. RS232 p/puerto 2 */ 

04361 #define RS232_IRQ 4 /* vector interrup. RS232 p/puerto 1 */ 

04362 #define XT WINI IRQ 5 /* xt Winchester */ 

04363 #define FLOPPY IRQ 6 /* disco flexible */ 

04364 #define PRINTERIRQ 7 

04365 #define AT WINI IRQ 14 /* at Winchester */ 

04366 

04367 /* Número de interrupción a vector de hardware. */ 

04368 #define BIOS_VECTOR(irq) \ 

04369 (((irq) < 8 ? BIOS_IRQ0_VEC : BIOS_IRQ8_VEC) + ((irq) & 0x07)) 

04370 #define VECTOR(irq) \ 

04371 (((irq) < 8 ? IRQ0_VECTOR : IRQ8_VECTOR) + ((irq) & 0x07)) 

04372 

04373 /* Vectores de parámetros de disco duro BIOS. */ 

04374 #define WINI_0_PARM_VEC 0x41 
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04375 #defme WINI_1_PARM_VEC 0x46 
04376 

04377 /* Puertos del controlador de interrupciones 8259A. */ 

04378 #defme INT_CTL 0x20 /* puerto de E/S p/contrOI. interrup. */ 

04379 #defme INT_CTLMASK 0x21 /* activar bit s en este puerto inhabi. ints. */ 

04380 #defme INT2_CTL OxAO /* puerto E/S p/20. control, interrup. */ 

04381 #defme INT2_CTLMASK OxAl /* activar bits en este puerto inhabi. ints. */ 

04382 

04383 /* Números mágicos para el controlador de interrupciones. */ 

04384 #defme ENABLE 0x20 /* código p/rehabilitar después de una int. */ 

04385 

04386 /* Tamaños de las tablas de memoria. */ 

04387 #defme NR_MEMS 3 /* número de trozos de memoria */ 

04388 

04389 /* Puertos diversos. */ 

04390 #defme PCR 0x65 /* Registro de Control Plano */ 

04391 #defme PORT B 0x61 /* puerto E/S p/puerto B 8255 (tecl. alarma...) */ 

04392 #defme TIMER0 0x40 /* puerto E/S p/canal 0 temporizador */ 

04393 #defme TIMER2 0x42 /* puerto E/S p/canal 2 temporizador */ 

04394 #defme TIMER_MODE 0x43 /* puerto E/S p/control de modo temporiz. */ 

04395 

04396 #endif /* (CHIP = INTEL) */ 

04397 

04398 #if (CHIP == M68000) 

04399 

04400 #defme K STACK BYTES 1024 /* núm. bytes para pila del kemel */ 

04401 

04402 /* Tamaños de tablas de memoria. */ 

04403 #defme NR_MEMS 2 /* número de trozos de memoria */ 

04404 

04405 /* p_reg contiene: d0-d7, a0-a6, en ese orden. */ 

04406 #defme NR REGS 15 /*# regs. grales. en cada ranura proc. */ 

04407 

04408 #defme TRACEBIT 0x8000 /* O esto conpsw en proc [] p/rastreo */ 

04409 #defme SETPSW(rp, new) /* permite activar sólo ciertos bits */ \ 

04410 ((rp) ->p_reg.psw = (rp) ->p_reg.psw & -OxFF : (new) & OxFF) 

04411 

04412 #defme MEM BYTES Oxffffffff /* tamaño de memoria para /dev/mem */ 

04413 

04414 #ifdef-ACK- 
04415 #defme FSTRUCOPY 
04416 #endif 
04417 

04418 #endif /* (CHIP = M68000) */ 

04419 

04420 /* Lo siguiente pertenece a colas de planificación. */ 

04421 #define TASK_Q 0 /* tareas listas planif. vía cola 0 */ 

04422 #define SERVER Q 1 /* servidores listos planif. vía cola 1 */ 

04423 #define USER_Q- 2 /* usuarios listos planif. vía cola 2 */ 

04424 

04425 #if (MACHINE == ATAR!) 

04426 #define SHADOW_Q 3 /* procesos ejecutables pero en sombra */ 

04427 #defme NQ 4 /* núm. colas de planificación */ 

04428 #else 

04429 #defme NQ 3 /* núm. colas de planificación */ 

04430 #endif 
04431 

04432 /* Valores devueltos por Env_parse(). */ 

04433 #defme EP_UNSET 0 /* variable no establecida */ 

04434 #define EP_OFF 1 /* var = off */ 
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04435 #defmeEP_ON 2 /* var = on (o campo en blanco) */ 

04436 #defme EP_SET 3 /* var =1 :2:3 (campo no en blanco) */ 

04437 

04438 /* Para traducir una dirección en espacio de kemel a dir. física. Es lo mismo que 
04439 * umap(proc_ptr, D, vir, sizeof(*vir)), pero mucho menos costoso. 

04440 */ 

04441 #defme vir2phys(vir) (data_base + (vir_bytes) (vir)) 

04442 

04443 #defme printf printk /* el kernel usa printk, no printf */ 


src/kemel/type.h 


04500 #ifndef TVPEH 
04501 #defme TVPE H 
04502 

04503 typedef _PROTOTVPE( void task t, (void)); 

04504 typedef _PROTOTVPE( int (*rdwt_t), (message *m_ptr) ); 

04505 typedef _PROTOTVPE( void (*watchdog_t), (void)); 

04506 

04507 struct tasktab { 

04508 task_t *initial_pc; 

04509 int stksize; 

04510 charname[8]; 

04511 }; 

04512 

04513 struct memory { 

04514 phy s_clicks base; 

04515 phys_clicks size; 

04516 }; 

04517 

04518 /* Administración del escrutinio por reloj. */ 

04519 struct milli_state { 

04520 unsigned long accum_count; /* tics de reloj acumulados */ 

04521 unsigned prev_count; /* valor previo del reloj */ 

04522 }; 

04523 

04524 #if (CHIP = INTEL) 

04525 typedef unsigned port_t; 

04526 typedef unsigned segm_t; 

04527 typedef unsigned reg_t; /* registro de máquina */ 

04528 

04529 /* La organización del marco de pila depende del software, pero por eficiencia se 

04530 * organiza a modo de simplificar al máximo el código de ensamblador para usarlo. 

04531 * El modo 80286 protegido y todos los reales usan el mismo marco, hecho con 

04532 * registros de 16 bits. El modo real no tiene conmutación automática de pila, así 

04533 * que poco se pierde usando el marco 286 con él. El 386 sólo difiere en tener 

04534 * registros de 32 bit s y más registros de segmento. Se usan los mismos nombres en 

04535 * los registros para evitar diferencias en el código. 

04536 */ 

04537 struct stackframe_s { /* proc_ptr apunta aquí */ 

04538 #if WORD SIZE = 4 

04539 ul6_tgs; /* última cosa en pila por save */ 

04540 ul6_t fs; /* ’*/ 

04541 #endif 

04542 ul6_t es; /* I */ 

04543 ul6_t ds; /* I*/ 

04544 reg_t di; /* en C no se accede de di a ex */ 
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04545 

regt 

si; /* 

orden es p/concordar con pusha/popa */ 

04546 

regt 

fp; /* 

bp*/ 

04547 

regt 

st; /* 

agujero para otra copia de sp */ 

04548 

regt 

bx; /* 

|*/ 

04549 

regt 

dx; /* 

|*/ 

04550 

regt 

ex; /* 

|*/ 

04551 

regt 

retreg; /* 

ax y anteriores en pila por save */ 

04552 

reat 

retadr; /* 

dir. retomo p/save() en código ensamb. */ 

04553 

regt 

pe; /* 

" últ. cosa en pila por interrupción */ 

04554 

regt 

es; /* 

|*/ 

04555 

regt 

psw; /* 

|*/ 

04556 

regt 

sp; /* 

|*/ 

04557 

regt 

ss; /* 

en pila por- CPU durante interrupción */ 

04558 

}; 



04559 




04560 

struct 

segdescs { 

/* descriptor de segmento p/modo protegido */ 

04561 

U16 t 

iimitlow; 


04562 

ui6 t 

baselow; 


04563 

u8 t 

basemiddle 


04564 

u8 t 

access; /* 

|P|DL|1|X|E|R|A| */ 

04565 

#if WORDSIZE = ¿ 


04566 

u8 t 

granulan tv; 

/* |G|X|0|A1LIMT| */ 

04567 

u8 t 

basehigh; 


04568 

#else 



04569 

ul6 t 

reserved; 


04570 

#endif 



04571 

}; 



04572 




04573 

typedef 

PROTOTYPE( int ( *irqhandlert), (int irq)); 

04574 




04575 

#endif 

/* (CHIP == 

INTEL) */ 

04576 




04577 

#if (CHIP =- M68000) 

04578 

typedef 

PROTOTY 

PE( VOid (*dmaintt), (void)); 

04579 




04580 

typedef 

u32t regt;/* 

registro de máquina */ 

04581 




04582 

/* El nombre y campos de este struct se escogieron p/compatibilidad con PC. */ 

04583 

struct 

stackframe 

s{ 

04584 

reg t 

retreg; /* 

d0*/ 

04585 

reg t 

di ; 


04586 

reg t 

d2; 


04587 

reg t 

d3; 


04588 

reg t 

d4; 


04589 

reg t 

d5; 


04590 

reg t 

d6; 


04591 

reg t 

d7; 


04592 

reg t 

aO; 


04593 

reg t 

al; 


04594 

reg t 

a2; 


04595 

reg t 

a3; 


04596 

reg t 

a4; 


04597 

reg t 

a5; 


04598 

reg t 

fp; /* 

también conocido como a6 */ 

04599 

reg t 

sp; /" 

también conocido como a7 */ 

04600 

reg t 

pe; 


04601 

ul6 t 

pSW; 


04602 

U16 t 

dummy; /* 

hacer tamaño múltiplo de regt para system.c 

04603 

}; 



04604 
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04605 struct fsave { 

04606 struct cpu_state { 

04607 ul6_t i_format; 

04608 u32_t i_addr; 

04609 ul6_t i_state[4]; 

04610 } cpu_state; 

04611 struct state_frame { 

04612 u8_t frame_type; 

04613 u8_t frame_size; 

04614 ul 6_t reserved; 

04615 u8_t ffame[212]; 

04616 } stateframe; 

04617 struct fpp_model { 

04618 u32_tfpcr; 

04619 u32_t fpsr; 

04620 u32_t fpiar; 

04621 struct fpN { 

04622 u32_t high; 

04623 u32_t low; 

04624 u32_t mid; 

04625 } fpN[8]; 

04626 } fpp_model; 

04627 }; 

04628 #endif /* (CHIP = M68000) */ 
04629 

04630 #endif /* TYPE H */ 


src/kemel/proto.h +++++++++++++- 

04700 /* Prototipos de funciones. */ 
04701 

04702 #ifndef PROTO H 
04703 #defme PROTO_H 
04704 

04705 /* Declaraciones de struct. */ 
04706 struct proc; 

04707 struct tty; 

04708 

04709 /* at_wini.c, wini.c */ 


04710 _PROTOTYPE( void winchester task, (void) ); 

04711 _PROTOTYPE( void at_winchester_task, (void) ); 

04712 

04713 /* clock.c */ 

04714 _PROTOTYPE( void clock task, (void) ); 

04715 _PROTOTYPE( void clock stop, (void) ); 

04716 _PROTOTYPE( clock t get uptime, (void) ); 

04717 _PROTOTYPE( void syn alrm task, (void) ); 

04718 

04719/*dmp.c */ 

04720 _PROTOTYPE( void map_dmp, (void) ); 

04721 _PROTOTYPE( void p_dmp, (void) ); 

04722 _PROTOTYPE( void reg_dmp, (struct proc *rp) ); 

04723 

04724 /* dp8390.c */ 
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04725 _PROTOTYPE( void dp8390 task, (void) ); 

04726 _PROTOTYPE( void dp dump, (void) ); 

04727 _PROTOTYPE( void dp8390_stop, (void) ); 

04728 

04729 /* floppy.c, stfloppy.c */ 

04730 _PROTOTYPE( void floppy task, (void) ); 

04731 _PROTOTYPE( void floppy stop, (void) ); 

04732 

04733 /* main.c, stmain.c */ 

04734 _PROTOTYPE( void main, (void) ); 

04735 _PROTOTYPE( void panic, (const char *s, int n) ); 

04736 

04737 /* memory.c */ 

04738 _PROTOTYPE( void mem task, (void) ); 

04739 

04740 /* misc.c */ 

04741 _PROTOTYPE( int env parse, (char *env, char *fint, int field, 

04742 —long *param, long min, long max) ); 

04743 

04744 /* printer.c, stprint.c */ 

04745 _PROTOTYPE( void printer_task, (void) ); 

04746 

04747 /* proc.c */ 

04748 _PROTOTYPE( void interrupt, (int task) ); 

04749 _PROTOTYPE( int lock_mini_send, (struct proc *caller_ptr, 

04750 int dest, message *m_ptr) ); 

04751 _PROTOTYPE( void lock pick proc, (void) ); 

04752 _PROTOTYPE( void lock-ready, (struct proc *rp) ); 

04753 _PROTOTYPE( void lock-sched, (void) ); 

04754 _PROTOTYPE( void lock-unready, (struct proc *rp) ); 

04755 _PROTOTYPE( int sys cali, (int fünction, int src_dest, message *m_ptr)); 

04756 _PROTOTYPE( void unhold, (void) ); 

04757 

04758 /* rs232.c */ 

04759 _PROTOTYPE( void rs_init, (struct tty *tp) ); 

04760 

04761 /* system.c */ 

04762 _PROTOTYPE( void cause_sig, (int proc_nr, int sig_nr) ); 

04763 _PROTOTYPE( void inform, (void) ); 

04764 _PROTOTYPE( phys_bytes numap, (int proc_nr, vir_bytes vir_addr, 

04765 vir bytes bytes) ); 

04766 _PROTOTYPE( void sys task, (void) ); 

04767 _PROTOTYPE( phys b)4es umap, (struct proc *rp, int seg, vir_bytes vir_addr, 

04768 -vir_bytes bytes) ); 

04769 

04770 /* tty.c */ 

04771 _PROTOTYPE( void handle events, (struct tty *tp) ); 

04772 _PROTOTYPE( void sigchar, (struct tty *tp, int sig) ); 

04773 _PROTOTYPE( void tty task, (void) ); 

04774 _PROTOTYPE( int in_process, (struct tty *tp, char *buf, int count) ); 

04775 _PROTOTYPE( void out process, (struct tty *tp, char *bstart, char *bpos, 

04776 —char *bend, int *icount, int *ocount) ); 

04777 _PROTOTYPE( void tty_wakeup, (clock_t now) ); 

04778 _PROTOTYPE( void tty_reply, (int code, int replyee, int proc_nr, 

04779 int status) ); 

04780 _PROTOTYPE( void tty_devnop, (struct tty *tp) ); 

04781 

04782 /* biblioteca */ 

04783 PROTOTYPE( void *memcpy, (void *_sl, const void *_s2, size t _n) ); 

04784 
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04785 #if (CHIP = INTEL) 

04786 

04787 /* cloc~.c */ 

04788 _PROTOTYPE( void milli_start, (struct milli_state *msp) ); 

04789 _PROTOTYPE( unsigned milli_elapsed, (struct milli_state *msp) ); 

04790 _PROTOTYPE( void milli_delay, (unsigned millisec) ); 

04791 

04792 /* console.c */ 

04793 _PROTOTYPE( void cons_stop, (void) ); 

04794 _ PROTOTYPE( void putk, (int c) ); 

04795 _PROTOTYPE( void ser init, (struct tty *tp) ); 

04796 _PROTOTYPE( void toggle scroll, (void) ); 

04797 _PROTOTYPE( int con_loadfont, (phys_bytes user_phys) ); 

04798 _PROTOTYPE( void select_console, (int cons_line) ); 

04799 

04800 /* cstart.c */ 

04801 _PROTOTYPE( void cstart, (U16_t es, U16_t ds, U16_t mes, U16_t mds, 

04802 _U 16_t parmoff, U16_t parmsize) ); 

04803 _PROTOTYPE( char *k_getenv, (char *name) ); 

04804 

04805 /* exception.c */ 

04806 _PROTOTYPE( void exception, (unsigned vec nr) ); 

04807 

04808 /* i8259.c */ 

04809 _PROTOTYPE( irq_handler_t get_irq_handler, (int irq) ); 

04810 _PROTOTYPE( void put_irq_handler, (int irq, irq_handler_t handler) ); 

04811 _PROTOTYPE( void intr_init, (int mine) ); 

04812 

04813 /* keyboard.c */ 

04814 _PROTOTYPE( void kb init, (struct tty *tp) ); 

04815 _PROTOTYPE( int kbd=loadmap, lphys_bytes user_phys) ); 

04816 _PROTOTYPE( void wreboot, (int how) ); 

04817 

04818 /* klib*.s */ 

04819 _PROTOTYPE( void biosl3, (void) ); 

04820 _PROTOTYPE( phys_bytes check_mem, (phys_bytes base, phys_bytes size) ); 

04821 _PROTOTYPE( void cp_mess, (int src,phys_clicks src_clicks,vir_bytes src_offset, 

04822 _phys_clicks dst_clicks, vir_bytes dst_offset) ); 

04823 _PROTOTYPE( int in byte, (port t port) ); 

04824 _PROTOTYPE( int in=word, (port=t port) ); 

04825 _PROTOTYPE( void lock, (void) ); 

04826 _PROTOTYPE( void unlock, (void) ); 

04827 _PROTOTYPE( void enable irq, (unsigned irq) ); 

04828 _PROTOTYPE( int disable-irq, (unsigned irq) ); 

04829 _PROTOTYPE( ul6_t mem rdw, (segm t segm, vir bytes offset) ); 

04830 _PROTOTYPE( void out byte, (port t port, int valué) ); 

04831 _PROTOTYPE( void out=word, (port=t port, int valué) ); 

04832 _PROTOTYPE( void phys_copy, (phys_bytes source, phys_bytes dest, 

04833 phys_bytes count); 

04834 _PROTOTYPE( void port read, (unsigned port, phys_bytes destination, 

04835 _unsigned bytcount) ); 

04836 _PROTOTYPE( void port_read_byte, (unsigned port, phys_bytes destination, 

04837 _unsigned bytcount) ); 

04838 _PROTOTYPE( void port_write, (unsigned port, phys_bytes source, 

04839 _unsigned bytcount) ); 

04840 _PROTOTYPE( void port_write_byte, (unsigned port, phys_bytes source, 

04841 _unsigned bytcount) ); 

04842 _PROTOTYPE( void reset, (void) ); 

04843 _PROTOTYPE( void vid vid copy, (unsigned src, unsigned dst, unsigned count); 

04844 _PROTOTYPE( void mem=vid=cOPY, (ul6_t *src, unsigned dst, unsigned count»; 
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04845 _PROTOTYPE( void levelO, (void (*fimc) (void)) 

04846 _PROTOTYPE( void monitor, (void) 

04847 

04848 /* misc.c */ 

04849 _PROTOTYPE( void mem_init, (void) 

04850 

04851 /* mpx*.'s */ 

04852 _PROTOTYPE( void idle_task, (void) 

04853 _PROTOTYPE( void restart, (void) 

04854 

04855 /* Las siguientes nunca se invocan desde C (procs. asm puros). */ 

04856 

04857 /* Manejadores de excep. (modo real o protegido) en orden numérico. */ 

04858 void _PROTOTYPE( intOO, (void)), _PROTOTYPE( divide_error, (void)); 

04859 void_PROTOTYPE( intOl, (void)), _PROTOTYPE( single step exception, (void)); 

04860 void _PROTOTYPE( int02, (void)), _PROTOTYPE( nmi, (void)); 

04861 void _PROTOTYPE( int03, (void)), _PROTOTYPE( breakpoint exception, (void)); 

04862 void _PROTOTYPE( int04, (void)), _PROTOTYPE( overflow, (void)); 

04863 void _PROTOTYPE( int05, (void)), _PROTOTYPE( bounds_check, (void) ); 

04864 void _PROTOTYPE( int06, (void)), _PROTOTYPE( inval_opcode, (void)); 

04865 void PROTOTYPE( int07, (void)), _PROTOTYPE( copr not available, (void)); 
04866 void_PROTOTYPE( double_fault, (void)); 

04867 void_PROTOTYPE( copr seg overrun, (void)); 

04868 void_PROTOTYPE( inval_tss, (void)); 

04869 void_PROTOTYPE( segment_not_present, (void) ); 

04870 void_PROTOTYPE( stack exception, (void)); 

04871 void_PROTOTYPE( general_protection, (void)); 

04872 void_PROTOTYPE( page_fault, (void)); 

04873 void_PROTOTYPE( copr error, (void)); 

04874 

04875 /* Manejadores de interrupciones de hardware. */ 

04876 _PROTOTYPE( void hwintOO, (void)); 

04877 _PROTOTYPE( void hwintOl , (void)); 

04878 _PROTOTYPE( void hwint02, (void)); 

04879 _.PROTOTYPE( void hwint03, (void)); 

04880 _PROTOTYPE( void hwint04, (void)); 

04881 _PROTOTYPE( void hwint05, (void)); 

04882 _PROTOTYPE( void hwint06, (void)); 

04883 _PROTOTYPE( void hwint07, (void)); 

04884 _PROTOTYPE( void hwint08, (void)); 

04885 _PROTOTYPE( void hwint09, (void)); 

04886 _PROTOTYPE( void hwintlO, (void)); 

04887 _PROTOTYPE( void hwintl 1 , (void)); 

04888 _PROTOTYPE( void hwintl2, (void)); 

04889 _PROTOTYPE( void hwintl3, (void)); 

04890 _PROTOTYPE( void hwintl4, (void)); 

04891 _PROTOTYPE( voidhwintl5, (void)); 

04892 

04893 /* Manejadores de interrupciones de software, en orden numérico. */ 

04894 _PROTOTYPE( void trp, (void) ); 

04895 _PROTOTYPE( void s_call, (void)), _PROTOTYPE( p_s_call, (void) ); 

04896 _PROTOTYPE( void level0_call, (void) ); 

04897 

04898 /* printer.c */ 

04899 _PROTOTYPE( void pr restart, (void) 

04900 

04901 /* protectc */ 

04902 _PROTOTYPE( void prot init, (void) 

04903 _PROTOTYPE( void init_codeseg, (struct segdesc_s *segdp, phys_bytes base, 
04904 _phys_bytes size, int privilege) ); 
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04905 _PROTOTYPE( void init_dataseg, (struct segdesc_s *segdp, phys_bytes base, 

04906 _phys_bytes size, int privilege) ); 

04907 _PROTOTYPE( phys bytes seg2phys, (U16_t seg) ); 

04908 _PROTOTYPE( void enable_iop, (struct proc *pp) ); 

04909 

04910 /* pty.c */ 

04911 PROTOTYPE( void do_pty, (struct tty *tp, message *m_ptr) ); 

04912 PROTOTYPE( void pty_init, (struct tty *tp) ); 

04913 

04914 /* system.c */ 

04915 _PROTOTYPE( void alloc_segments, (struct proc *rp) ); 

04916 

04917 #endif /* (CHIP = INTEL) */ 

04918 

04919 #endif /* PROTO_H */ 


05000 

05001 

05002 

05003 

05004 

05005 

05006 

05007 

05008 

05009 

05010 

05011 

05012 

05013 

05014 

05015 

05016 

05017 

05018 

05019 

05020 

05021 

05022 

05023 

05024 

05025 

05026 

05027 

05028 

05029 

05030 

05031 

05032 

05033 

05034 
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/* Variables globales empleadas en el kemel. */ 

/* EXTERN se define como extern excepto en table.c. */ 
#ifdef_TA8LE 
#undef EXTERN 
#define EXTERN 
#endif 


/* Memoria del kemel. */ 

EXTERN phys_bytes code_base; /* base del código del kemel */ 
EXTERN phys_bytes data_base; /* base de datos del kemel */ 

/* Comunicaciones de interrupciones de bajo nivel. */ 

EXTERN struct proc *held_head; /* cabeza de cola de ints. detenidas */ 
EXTERN struct proc *held_tail; /* final de cola de ints. detenidas */ 
EXTERN unsigned char k_reenter; /* cuenta reingreso kemel (ingreso -1) */ 


/* Tabla de procesos. Aquí para no tener que incluir tantas veces proc.h. */ 

EXTERN struct proc *proc_ptr; /* apunto a proc. actual, en ejecución */ 

/* Señales.*/ 

EXTERN int sig_procs; /* # procs. con p_pending != 0 */ 

/* Tamaños de memoria. */ 

EXTERN struct memory mem[NR_MEMS]; /* base y tamaño de trozos de memo */ 
EXTERN phys_clicks tot_mem_size; /* tamaño total de memo del sistema */ 


/* Diversas. */ 
extern ul61 sizes[]; 
extern struct tasktab tasktabj] ;/* inic. 
extern char *t_stack[]; 
EXTERN unsigned lost_ticks; 
EXTERN clock_t tty_timeout; 
EXTERN int current; 


/* tabla llenada por monitor arranque */ 

. table.c, así que extern aquí */ 

/* inic. en table.c, así que extern aquí */ 

/* tics contados afuera de tarea de reloj */ 
/* tiempo para despertar la tarea TTY */ 
/* consola actualmente visible */ 
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05035 

05036 

05037 

05038 

05039 

05040 

05041 

05042 

05043 

05044 

05045 

05046 

05047 

05048 

05049 

05050 

05051 

05052 

05053 

05054 

05055 

05056 

05057 

05058 

05059 

05060 

05061 

05062 

05063 

05064 

05065 

05066 

05067 

05068 

05069 

05070 

05071 

05072 

05073 

05074 

05075 

05077 

05078 


#if (CHIP == INTEL) 

/* Tipo de máquina. */ 

EXTERN int pe at; /* interfaz de hardware PC-AT compatible */ 

EXTERN int ps-mea; /* PS/2 con Micro Channel */ 

EXTERN unsigned int processor; /* 86, 186, 286, 386,*/ 
ft/WORD SIZE = 2 

EXTERN int protected_mode; /* no 0 si en modo Intel protegido */ 

#else 

#defme protected_mode 1 /* modo 386 implica modo protegido */ 

#endif 


/* Tipos de tarjetas de video. */ 

EXTERN int ega; /* no 0 si consola es EGA o VGA */ 

EXTERN int vga; /* no 0 si consola es VGA */ 

/* Tamaños de memoria. */ 

EXTERN unsigned ext_memsize; /* inic. por cód. arranque ensamblador */ 

EXTERN unsigned low_memsize; 

/* Diversas. */ 

EXTERN irq_handler_t irq_table[NR_IRQ_VECTORS]; 

EXTERN int irq_use; /* mapa bits de todos irq en uso */ 

EXTERN reg_t mon_ss, mon_sp; /* pila del monitor */ 

EXTERN int mon_retum; /* true si se puede regresar a monitor */ 

EXTERN phYS_bytes reboot_code; /* programa p/monitor de arranque */ 

/* Variables inicializadas en otro lado son sólo extern aquí. */ 

exterrr struct segdesc_s gdt[]; /* tabla descriptores globales p/modo prot.*/ 

EXTERN _PROTOTYPE( void (*level0_func), (void)); 

#endif /* (CHIP — INTEL) */ 

#if (CHIP = M68000) 

/* Variables inicializadas en otro lado son sólo extern aquí. */ 
extern int keypad; /* Bandera p/modo subteclado num. */ 

extern int app_mode; /* Bandera p/modo aplico tecla flecha */ 

extern int STdebKey; /* no 0 si se detecta ctl-alt-Fx */ 

extern struct tty *cur_cons; /* cons. virtual ahora exhibida */ 
extern unsigned char font8[]; /* tabla fuentes 8 pix. ancho (inic.) */ 
extern unsigned char fontl2[]; /* tabla fuentes 12 pix. ancho (inic.) */ 05076 extern unsigned char fontl6[]; /* tabla fuentes 16 pix. i 
extern unsigned short resolution; /* def. pantalla; ST_RES_LOW. ,TT_RES_HIGH */ 

#endif 
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05110 struct proc { 

05111 struct stackframe_s p_reg; /* regs. de proc. guardados en marco pila */ 

05112 

05113 #if (CHIP = INTEL) 

05114 reg t p ldt sel; /* se lector en gdt da base y límite ldt */ 

05115 strüct segdesc_s p_ldt[2]; /* descriptores locales p/cód. y datos */ 

05116 /* 2 es LDT SIZE -evita incluir protect.h */ 

05117 #endif /* (CHIP = INTEL) */ 

05118 

05119 reg_t *p_stguard; /* palabra guardia de la pila */ 

05120 

05121 int p_nr; /* # de este proc. (p/acceso rápido) */ 

05122 

05123 int p_int_blocked; /* no 0 si mens. int. bloqueado por tarea ocup.*/ 

05124 int p_int_held; /* no 0 si mens. int. detenido por llamada ocup.*/ 

05125 struct proc *p_nextheld; i* sigte. en cadena de proc. int. detenidos */ 

05126 

05127 intp flags; /* P SLOT FREE, SENDING, RECEIVING, etc. */ 

05128 struct mem map p_map[NR_SEGS];/* mapa de memoria */ 

05129 pid_t p_pid; i * id de proceso pasado desde MM *í 

05130 

05131 clock_t user_time; /* tiempo de usuario en tics */ 

05132 clock_t sys_time; /* tiempo de sistema en tics *i 

05133 clock_t child_utime; i* tiempo de usuario acum. de hijos */ 

05134 clock_t child_stime; /* tiempo de sist. acumulado de hijos */ 

05135 clock_t p_alarm; /* tiempo de sigte. alarma en tics, 00*/ 

05136 

05137 struct proc *p_callerq; /* cabeza de lista de procs. quieren enviar */ 

05138 struct proc *p_sendlink; í* vine, a sigte. proc. quiere enviar */ 

05139 message *p_messbuf; /* apuntador a buffer de mensaje */ 

05140 int pgetfrom; /* ¿de quién quiere recibir el proc.? */ 

05141 intp_sendto; 

05142 

05143 struct proc *p_nextready; /* apunto a sigte. proceso listo */ 

05144 sigset_t p_pending; /* mapa bits p/señales pendientes */ 

05145 unsigned p_pendcount; /* cuenta de señales pendo e inconclusas */ 

05146 

05147 charp_name[16]; /* nombre del proceso */ 

05148 }; 

05149 

05150 /* Palabra guardia para pilas de tareas. */ 

05151 #defme STACK GUARD ((reg_t) (sizeof(reg_t) = 21 OxBEEF : OxDEADBEEF)) 

05152 

05153 /* Bits para p_flags en proc[]. Un proc. es ejecutable si p_flags == 0. */ 

05154 #defme P_SLOT_FREE 001 /* activado si ranura no está en uso */ 

05155 #defmeNO_MAP 002 /* evita se ejecute hijo bifurcado sin mapa */ 

05156 #defíne SENDING 004 /* ene. si proc. bloqueado tratando de enviar */ 

05157 #defme RECEIVING 010 /* ene. si proc. bloqueado tratando de rec. */ 

05158 #defíne PENDING 020 /* ene. si inform() de señal pendiente */ 

05159 #defme SIG PENDING 040 /* evita se ejecute proc. por señalizar */ 

05160 #defíneP_STOP 0100 /* ene. si proc. está siendo rastreado */ 

05161 

05162 /* Direcciones mágicas de tabla de procesos. */ 

05163 #defme BEGPROCADDR (&proc[0]) 

05164 #defme END PROC ADDR (&prOc[NR_TASKS + NR_PROCS]) 

05165 #defme END TASK ADDR (&proC[NR_TASKS]) 

05166 #defme BEG SERV ADDR (&prOc[NR_TASKS]) 

05167 #defme BEG USER ADDR (&prOc[NR_TASKS + LOWJJSER]) 

05168 

05169 #defme NIL_PROC ((struct proc *) 0) 
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05170 #define isidlehardware(n) ((n) = IDLE :: (n) = HARDWARE); 

05171 #defme isokprocn(n) ((unsigned) ((n) + NRTASKS) < NR_PROCS + NRTASKS); 

05172 #defme isoksrc_dest(n) (isOkprocn(n):: (n) = ANY); 

05173 #defme isoksusem(n) ((unsigned) (n) < NR PROCS); 

05174 #derine isokusem(n) ((unsigned) ((n) -LOW_USER) < NR_PROCS -LOWJJSER); 

05175 #defme isrxhardware(n) ((n) = ANY :: (n) == HARDWARE); 

05176 #defme issysentn(n) ((n) = FS_PROC_NR :: (n) = MM_PROC_NR); 

05177 #defme istaskp(p) ((p) < END TASK ADDR && (p) != proc_addr(IDLE)); 

05178 #defme isuserp(p) ((p) > = 8EG USER ADDR); 

05179 #defme proc_addr(n) (pproc_addr + NR TASKS) [(n)]; 

05180 #defme cproc_addr(n) (&(proc + NR_TASKs)[(n)]); 

05181 #defme proc_number(p)((p) ->p_nr); 

05182 #defme proc vir2phys(p, vir) \; 

05183 -(((Phys_bytes)(p)->p_maplD 1 .mem_phys « CLICK_SHIFT)\; 

05184 _ (vir_bytes\ (vir\\ 

05185 

05186 EXTERN struct proc proc[NR_TASKS + NR PROCS]; j* tabla de procesos *; 

05187 EXTERN struct proc *pproc_addr[NR_TASKS + NR_PROCS]; 

05188 * apunts. a ranuras de tabla proc.; rápido porque ahora puede encontrarse 

05189 una entrada indizando pproc_addr, mientras que acceder al elemento i requiere 
05190 multiplicar por sizeof(struct proc) pjdeterm. la dirección *; 

05191 EXTERN struct proc *bill_ptr; j* apunto a proc. al que se cobrarán tics *; 

05192 EXTERN struct proc *rdy_head[NQ]; ;* apunts. a cabo listas de p. listos *; 

05193 EXTERN struct proc *rdy_tail[NQ]; ;* apunts. a fin. listas de p. listos *; 

05194 

05195 #endif j* PROC H *; 


srcjkemeljprotect.h 


05200 * Constantes para modo protegido. *; 

05201 

05202 * Tamaños de tablas. *; 

05203 #define GDT SIZE (FIRSTLDTINDEX + NR TASKS + NR_PROCS) j* espec. y LDT *; 

05204 #define IDT SIZE (IRQ8_VECTOR + 8) * sólo hasta vector más alto *; 

05205 #define LDT SIZE 2 * contiene sólo CS y DS *; 

05206 

05207 * Descriptores globales fijos. 1 a 7 prescritos por BIOS. *; 

05208 #define GDTINDEX 1 * descriptor GDT *; 

05209 #define IDTINDEX 2 * descriptor IDT *; 

05210 #define DS INDEX 3 *DS de kemel*; 

05211 #define ES INDEX 4 * ES de kemel (386: bando 4 Gb al arranque) *; 

05212 #define SS INDEX 5 * SS de kemel (386: SS monitor al arranque) *; 

05213 #define CSINDEX 6 * CS de kemel*; 

05214 #define MON CS INDEX 7 * temp pj BIOS (386: CS monitor al arranque) *; 

05215 #define TSS INDEX 8 * TSS de kernel *; 

05216 #define DS_286_INDEX 9 * segmento origen 16 bits temporal *; 

05217 #define ES_286_INDEX 10 * segmento destino 16 bits temporal; 

05218 #define VIDEO INDEX 11 * segmento de memoria de video *; 

05219 #define DP ETH0 INDEX 12 * buffer Etherplus de Western Digital *; 

05220 #define DP ETHl INDEX 13 * buffer Etherplus de Western Digital *; 

05221 #define FIRST LDT INDEX 14 * resto de descriptores son LDT *; 

05222 

05223 #define GDT SELECTOR * (GDT INDEX * DESC_SIZE) mal para asid *; 

05224 #define IDT SELECTOR * (IDT INDEX * DESC_SIZE) *; 
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05225 #define DSSELECTOR 0x18 /* (DSJNDEX * DESCJ3IZE) */ 

05226 #defme ES SELECTOR 0x20 /* (ES_INDEX * DESC_SIZE) */ 

05227 #defme FLATDSSELECTOR 0x21 /* ES menos privilegiado */ 

05228 #defm'e SS_SELECTOR 0x28 /* (SS_INDEX * DESC_SIZE) */ 

05229 #defíne CS SELECTOR 0x30 /* (CSJNDÉX * DESCJ3IZE) */ 

05230 #defíne MONCSSELECTOR 0x38 /* (MON_CS_INDEX * DESC_SIZE) */ 

05231 #defme TSS SELECTOR 0x40 /*. (TSS_INDEX * DESC_SIZE) */ 

05232 #defme DS 286 SELECTOR 0x49 /* (DS_286_INDEX * DESC_SIZE + 1) */ 

05233 #defme ES 286 SELECTOR 0x51 /* (ES_286_INDEX * DESC_SIZE + 1) */ 

05234 #defme VIDEO SELECTOR 0x59 /* (VIDEO_INDEX * DESC_SIZE + 1) */ 

05235 #defme DP ETHO SELECTOR 0x61 /* (DP ETHO INDEX * DESC_SIZE) */ 

05236 #defme DPETHl SELECTOR 0x69 /* (DP ETHl INDEX * DESC_SIZE) */ 

05237 

05238 /* Descriptores locales fijos. */ 

05239 #define CS LDT INDEX 0 /* CS de proceso */ 

05240 #define DS LDT INDEX 1 /* DS=ES=FS=GS=SS de proceso */ 

05241 

05242 /* Privilegios. */ 

05243 #define INTR_PRIVILEGE 0 /* manejadores de kernel e interrup. */ 

05244 #defme TASK PRIVILEGE 1 

05245 #defme USERPRIVILEGE 3 

05246 

05247 /* Constantes de hardware de 286. */ 

05248 

05249 /* Números de vectores de excepción. */ 

05250 #define BOUNDS VECTOR 5 /* falló verificación de límites */ 

05251 #defíne INVAL OP VECTOR 6 /* cód. de operación no válido */ 

05252 #define COPROC_NOT_VECTOR 7 /* coprocesador no disponible */ 

05253 #define DOUBLE FAULT VECTOR 8 

05254 #define COPROC SEG VECTOR 9 /* segmento de coproc. invadido */ 

05255 #define INVAL TSS VECTOR 10 /* TSS no válido */ 

05256 #define SEG NOT VECTOR 11 /* segmento no presente */ 

05257 #define STACK FAULT VECTOR 12 /* excepción de pila */ 

05258 #define PRDTECTIONVECTOR13 /* protección general */ 

05259 

05260 /* Selector de bits. */ 

05261 #define TI 0x04 /* indicador de tabla */ 

05262 #define RPL 0x03 /* nivel de privil. de solicitante */ 

05263 

05264 /* Distancias en estructura de descriptores. */ 

05265 #define DESC BASE 2 í* a basejow */ 

05266 #define DESC BASE MIDDLE 4 /* a base_middle */ 

05267 #define DESC ACCESS 5 /* al byte de acceso */ 

05268 #define DESC_SIZE 8 /* sizeof (struct segdesc_s) */ 

05269 

05270 /* Tamaños de segmentos. */ 

05271 #define MAX_286_SEG_SIZE OxlOOOOL 
05272 

05273 /* Tamaños y desplazamientos de base y límite. */ 

05274 #define BASE MIDDLE SHIFT 16 /* despl. para base -> basejniddle */ 

05275 

05276 /* Bits de byte de acceso y byte de tipo. */ 

05277 #define PRESENT 0x80 /* encend. si descriptor presente */ 

05278 #define DPL 0x60 /* máscara nivel privil. descriptor */ 

05279 #define DPL SHIFT 5 

05280 #define SEGMENT 0x10 /* encend. p/descriptores tipo segmento */ 

05281 

05282 /* Bits de byte de acceso. */ 

05283 #define EXECUTABLE 0x08 /* encend. p/segmento ejecutable */ 

05284 #define CONFORMING 0x04 /* ene. p/segmento conformante si ejecutable */ 
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05285 #defme EXPAND DOWN 0x04 /* ene. p/segm. expand-abajo si no ejecutable */ 

05286 #defme READABLE 0x02 /* ene. p/seg. legible si ejecutable */ 

05287 #defme WRITEABLE 0x02 /* ene. p/seg. escribible si no ejecutable */ 

05288 #defme TSS BUSY 0x02 /* encend. si descriptor TSS ocupado */ 

05289 #define ACCESSED 0x01 /* encend. si segmento accedido */ 

05290 

05291 /* Tipos de descriptores especiales 

05292 #defme AVL 286 TSS 1 

05293 #defme LDT- -2 

05294 #defme BUSY_286_TSS 3 

05295 #defme CALL 286 GATE 4 

05296 #defme TASK-GATE 5 

05297 #defme INT_286_GATE 6 

05298 #defme TRAP 286 GATE 

05299 

05300 /* Constantes de hardware 386 extra. */ 

05301 

05302 /* Números de vectores de excepción. */ 

05303 #defme PAGE FAULT VECTOR 14 

05304 #defme COPROC_ERR=VECTOR 16 /* error de coprocesador */ 

05305 

05306 /* Distancias en la estructura de descriptores. */ 

05307 #define DESC GRANULARITY 6 /* a byte de granularidad */ 

05308 #defme DESC BASE HIGH 7 /* a base_high */ 

05309 

05310 /* Tamaños y desplazamientos de base y límite. */ 

05311 #defme BASE HIGH SHIFT 24 /* despl. para base -> base_high */ 

05312 #defíne BYTE-GRAN-MAX OxFFFFFL /* tamaño máx. p/segm. con granul. byte * 
05313 #defme GRANULARITY SHIFT 16 /* despl. para límite —> granularidad */ 

05314 #defme OFFSET HIGH-SHIFT 16 /* despl. p/díst. (comp.) -.> offset_high */ 

05315 #defme PAGE_GRAN_SHIFT 12 /* despl. extra p/límites con granul. pág. */ 

05316 

05317 /* Bits de byte de tipo. */ 

05318 #defme DESC 386 BIT 0x08 /* tipos 386 obtenidos haciendo OR con esto */ 

05319 -/* LDT Y TASK GATE no lo necesitan */ 

05320 

05321 /* Byte de granularidad 

05322 #define GRANULAR 

05323 #define DEFAULT 

05324 #define BIG 

05325 #defíne AVL 

05326 #defíne LIMIT HIGH 


src/kemel/sconst.h 


05400 Constantes diversas empleadas en código ensamblador. 

05401 W=_WORD_SIZE! Tamaño de palabra de máquina. 

05402 

05403 ! Distancias en struct proc. DEBEN coincidir con proc.h. 

05404 PSTACKBASE = 0 

05405 #if WORD SIZE = 2 

05406 ESREG -= P STACKBASE 

05407 #else 

05408 GSREG = P STACKBASE 

05409 FSREG = GSREG + 2 ! 386 introduce segmentos FS y GS 


0x80 /* encend. p/granularídad de 4K */ 

0x40 /* ene. p/predeterm. 32 bits (seg. ejec.) */ 
0x40 /* ene. para "BIG" (seg. expand-abajo) */ 
0x10 /* 0 para disponible */ 

OxOF /* máscara p/bits altos del límite */ 


/* disponible 286 TSS */ 

/* tabla de descriptores local */ 

/* ene. transparentemente al software */ 

/* no utilizado */ 

/* empleado sólo por depurador */ 

/* compuerta interrup., usada p/todos vectores */ 
7 /* no utilizado */ 
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05410 ESREG 
05411 #endif 
05412 DSREG 
05413 DIREG 
05414 SIREG 
05415 BPREG 
05416 STREG 
05417 BXREG 
05418 DXREG 
05419 CXREG 
05420 AXREG 
05421 RETADR 
05422 PCREG 
05423 CSREG 
05424 PSWREG 
05425 SPREG 
05426 SSREG 
05427 PSTACKTOP 
05428 PLDTSEL 
05429 PLDT 
05430 

05431 #if _WORD_SIZE = 2 

05432 Msize 

05433 #else 

05434 Msize 

05435 #endif 


FSREG + 2 


ESREG+ 2 
DSREG+2 
DIREG + W 
SIREG+ W 
BPREG+ W 
STREG + W 
BXREG+ W 
DXREG+ W 
CXREG+ W 
AXREG+ W 
RETADR+ W 
PCREG + W 
CSREG+ W 
PSWREG + W 
SPREG + W 
SSREG+ W 
PSTACKTOP 


! agujero para otro SP 


! dir. de retomo p/llamada save() 


12 ! tamaño de mensaje en palo de 16 bits 

9 ! tamaño de mensaje en palo de 32 bits 


src/kemel/assert.h 


05500 

05501 

05502 

05503 

05504 

05505 

05506 

05507 

05508 

05509 

05510 

05511 

05512 

05513 

05514 

05515 

05516 

05517 

05518 

05519 

05520 

05521 

05522 

05523 

05524 


/* 

assert.h 

#ifhdef ASSERTH 
#defme ASSERTH 

#if DEBUG 


#defme INITASSERT static char *assert_file= -FILE-; 


void bad_assertion(char *file, int line, char *what); 

void bad_compare(char *file, int line, int lhs, char *what, int rhs); 


#defme assert(x) 
#defme compare(a,t,b) 
#else 1* ! DEBUG *1 


(! (x) ? bad_assertion(assert_file, -LINE-, #x) \ 

: (void) 0) 

(! ((a) t (b)) ? bad_compare(aSsert_file, -LINE—, \ 

(a), #a', #t', #b, (b)): (void) 0) 


#defme INIT ASSERT 1 * nada * 1 

#defíne assert(x) (void)0 

#defme compare(a,t,b) (void)0 


#endif 1* !DEBUG *1 
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05525 

05526 #endif /* ASSERT H */ 



05600 /* El arch. objeto de "table.c" contiene todos los datos. En los arch. *.h, 

05601 * las variables declaradas llevan EXTERN antes, como en 

05602 * 

05603 * EXTERN int x; 

05604 * 

05605 * Normalmente EXTERN se define como extern, para que cuando las variables 

05606 * se incluyan en otro archivo no se les asigne memoria. Si no estuviera 

05607 * presente EXTERN, sino sólo digamos, 

05608 * 

05609 * int X; 

05610 * 

05611 * la inclusión de este arch. en varios arch. fuente haría que ’x' se declarara 

05612 * varias veces. Algunos vinculado res aceptan esto, otros no, así que se 

05613 * declaran extern al incluirse normalmente, pero deben declararse realmente 

05614 * en algún lado. Eso se hace aquí, redefiniendo EXTERN como la cadena nula 

05615 * para que la inclusión de todos los arch. *.h de table.c sí genere memoria 

05616 * para ellos. Todas las variables inicializadas también se declaran aquí, 

05617 * ya que 

05618 * 

05619 * extern int x = 4; 

05620 * 

05621 * no se permite. Si tales variables se comparten, también deberán declararse 

05622 * en uno de los archivos *.h sin la inicialización. 

05623 */ 

05624 

05625 #define TABLE 

05626 

05627 #include "kemel.h" 

05628 #include <termios.h> 

05629 #include <minix/com.h> 

05630 #include "proc.h" 

05631 #include "tty.h" 

05632 

05633 /* A continuación se da la rutina de arranque de cada tarea, de -NR_TASKS para 

05634 * arriba. El orden de los nombres aquí DEBE coincidir con los valores 

05635 * numéricos asignados a las tareas en <minix/com.h>. 

05636 */ 

05637 #define SMALLSTACK (128 * sizeof(char *)) 

05638 

05639 #define TTY STACK (3 * SMALL STACK) 

05640 #define SYN ALRM STACK SMALL STACK 
05641 

05642 #define DP8390_STACK (SMALL STACK * ENABLE NETWORKING) 

05643 

05644 #if (CHIP = INTEL) 

05645 #define IDLESTACK ((3+3+4) * sizeof(char *)) /* 3 intr, 3 temps, 4 db */ 

05646 #else 

05647 #define IDLE STACK SMALL STACK 

05648 #endif 

05649 
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05650 #defme PRINTERSTACK SMALLSTACK 
05651 

05652 #if (CHIP = INTEL) 

05653 #defme WINCHSTACK (2 * SMALL STACK * ENABLEWINI) 

05654 #else 

05655 #defme WINCH STACK (3 * SMALL STACK * ENABLE WINI) 

05656 #endif 
05657 

05658 #if (MACHINE = ATARI) 

05659 #defme SCSI_STACK (3 * SMALL STACK) 

05660 #endif 
05661 

05662 #if (MACHINE = IBMPC) 

05663 #defme SCSI_STACK (2 * SMALL STACK * ENABLE SCSI) 

05664 #endif 
05665 

05666 #defme CDROMSTACK (4 * SMALL STACK * ENABLE CDROM) 

05667 #defme AUDIO_STACK (4 * SMALL STACK * ENABLEAUDIO) 

05668 #defme MIXERSTACK (4 * SMALL STACK * ENABLE AUDIO) 

05669 

05670 #defme FLOP_STACK (3 * SMALL STACK) 

05671 #define MEMSTACK SMALLSTACK 

05672 #defme CLOCKSTACK SMALL STACK 

05673 #defme SYS STACK SMALL STACK 

05674 #defme HARDWARESTACK 0 -/* tarea ficticia, usa pila del kemel */ 

05675 

05676 

05677 #defme TOT STACK SPACE (TTY STACK + DP8390_STACK + SCSI_STACK + 

05678 SYNALRMSTACK + IDLESTACK + HARDWARESTACK + PRINTERSTACK + \ 
05679 WINCHSTACK + FLOP_STACK + MEMSTACK + CLOCKSTACK + SYS_STACK + \ 
05680 CDROMSTACK + AUDIO_STACK + MIXERSTACK) 

05681 

05682 

05683 /* SCSI, CDROM y AUDIO podrían tener en el futuro diferentes opciones como 

05684 * WINCHESTER, pero por ahora la opción es fija. 

05685 */ 

05686 #define scsi_task aha_scsi_task 

05687 #define cdrom_task mcd_task 

05688 #define audio_task dsp_task 

05689 
05690 

05691 /* 

05692 * Algunas notas respecto a la tabla siguiente: 

05693 * 1) La tty_task siempre debe ser la primera para que otras tareas puedan usar 

05694 * printf si su inicialización tiene problemas. 

05695 * 2) Si ud. agrega una nueva tarea de kemel, hágalo antes de la de impresora. 

05696 * 3) Se usa el nombre de tarea como nombre de proceso (p name). 

05697 */ 

05698 

05699 PUBLIC struct tasktab tasktab[] = { 

05700 {tty_task, TTY STACK, "TTY" }, 

05701 #if ENABLENETW ORKING 

05702 {dp8390_task, DP8390_STACK, "DP8390, }, 

05703 #endif 

05704 #ifENABLE_CDROM 

05705 {cdromtask, CDROMSTACK,"CDROM" }, 

05706 #endif 

05707 #if ENABLEAUDIO 

05708 {audio_task, AUDIO_STACK, "AUDIO" }, 

05709 {mixer task, MIXER STACK, "MIXER" }, 
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05710 

#endif 



05711 

#if ENABLE SCSI 



05712 

{ scsi task, 

SCSI STACK, 

"SCSI" }, 

05713 

#endif 



05714 

#if ENABLE WINI 



05715 

{Winchester task, 

WINCH STACK, "WINCH" }, 

05716 

#endif 



05717 

{ syn alrm task, 

SYN ALRM ST 

ACK, "SYN AL" }, 

05718 

{idle task, 

IDLE STACK, 

"IDLE" }, 

05719 

{printer task, 

PRINTER STACK, "PRINTER" }, 

05720 

{ floppy task. 

FLOP STACK, 

"FLOPPY" }, 

05721 

{ mem task, 

MEM STACK, 

"MEMORY" }, 

05722 

{ dock task, 

CLOCK STACK 

"CLOCK" }, 

05723 

{ sys task, 

SYS STACK, 

"SYS" }, 

05724 

{0, HARDWARE STACK, "HARDWAR" 

}, 

05725 

{0, 0, 

"MM" 

}, 

05726 

{0, 0, 

"FS" 

}, 

05727 

#if ENABLE NETWORKING 



05728 

{0, 0, 

"INET" 

}, 

05729 

#endif 



05730 

{0, 0, 

"INIT" 

}, 

05731 



}; 

05732 




05733 

* Espacio de pila p/todas pilas de tarea 

(Declarado (char 

) p/alinearlo.) * 

05734 

PUBLIC char*t stack[TOT STACK 

SPACE I sizeof(ch 

ir*)]; 

05735 




05736 




05737 

* El número de tareas de kemel debe s 

sr igual que NR TASKS. 

05738 

* Si NR TASKS no es correcto, se obtendrá el error de co 

mpilador: 

05739 

* "array size is negative" 



05740 

* 



05741 




05742 

#defme NKT (sizeof tasktab I sizeof (struct tasktab) -(INI 1 

T PROC NR+ 1)) 

05743 




05744 

extern int dummy_tasktab_check[NR 

TASKS = NKT? 

1:-1]; 



src/kemel 

mpx. 

05800 

# 



05801 

/* Elige entre las versiones 8086 Y 386 del código de arranque de Minix.*/ 

05802 




05803 

#include <minix/config.h> 05804 #i 

WORD SIZE == 

2 05805 #include "mpx88.s" 

05806 

#else 



05807 

#include "mpx386.s" 



05808 

#endif 
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src/kemel/mpx3 86. s 


05900 /* 

05901 * Este archivo contiene el código de arranque en ensamblador para Minixy los 05902 ! manejadores de interrup. de 32 bits. Coopera con start.c para establecer un 

05903 * buen entorno para main(). 

05904 

05905 *Este arch. es parte de la capa más baja del kemel MINIX. La otra parte es 05906 ! "proc.c". Esta capa conmuta procesos y maneja mensajes. 

05907 

05908 * Toda transición al kemel pasa por este archivo. Causan transiciones el 05909 ! envío/recepción de mensajes y casi todas las interrupciones. 
05910 * interrupciones RS232 pueden manejarse en "rs2.s" y rara vez ingresan en el 05911 ! kemel.) 

05912 

05913 * Las transiciones al kemel pueden anidarse. El ingreso inicial puede ser 

05914 * con llamada al sistema, excepción o interrup. de hardware; los reingresos 

05915 * sólo pueden ser por int. de hard. La cuenta de reingresos se mantiene en 

05916 * "k.reenter". Es importante p/decidir si cambiar a la pila del kemel y p/ 

05917 * proteger el cód. de transí, de mensajes en "proc.c". 

05918 

05919 * Para la trampa de transí de mens., casi todo el estado de máq. se guarda 

05920 * en la tabla de proc. (Algunos regs. no tienen que guardarse.) Luego la pila 

05921 * se conmuta a "k.stack" y se rehabilitan las ints. Por último se invoca el 

05922 * manej. de llamadas (en C). Al regresar, las ints. se inhabilitan otra vez y 

05923 * el cód. continúa con la rutina de reinicio, para finalizar ints. Detenidas 

05924 * Y ejecutar el proc. o tarea cuyo apunto está en "proc_ptr". 

05925 

05926 * Los manejadores de ints. de hardware hacen lo mismo, excepto que (1) todo 

05927 * el estado debe guardarse. (2) Hay demasiados manejadores para hacerlo en 

05928 * línea; así, se invoca save. Se ahorran unos ciclos formando en pila la dir. 

05929 * de la rutina de reinic. adecuada para retomo posterior. (3) Se evita 

05930 * cambio de pila si ya se cambió. (4) El contr. de ints. (maestro) 8259 se 

05931 * rehabil. centralmente en save(). (5) Cada manejador enmascara su línea de 

05932 * int. con el 8259 antes de habilitar otras ints. (enmascaradas), y la 

05933 * desenmascara después de atender la int. Esto limita el nivel de anidación 

05934 * al núm. de líneas y protege al manejador contra sí mismo. 

05935 

05936 * Para comunicarse con el monitor de arranque al inicio algunos datos 

05937 * constantes se compilan al principio del segmento de texto. Esto facilita la 

05938 * lectura de los datos al comenzar el proc. de arranque, ya que sólo hay que 

05939 * leer el primer sector del archivo. 

05940 

05941 * También se asigna memoria a datos al final de este archivo. Estos datos 

05942 * estarán al principio del segm. de datos del kemel y serán leídos y 

05943 * modificados por el monitor de arranque antes de que el kemel inicie. 

05944 

05945 * secciones 

05946 

05947 sect .text 

05948 #begtext: 

05949 #sect .rom 

05950 begrom: 

05951 .sect .data 

05952 begdata: 

05953 .sect .bss 

05954 begbss: 
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05955 

05956 #include <minix/config.h> 

05957 #include <minix/const.h> 

05958 #include <minix/com.h> 

05959 #include "const.h" 

05960 ’#include "protect.h" 

05961 #include "sconst.h" 

05962 

05963 /* Distancias tss 386 selectas. */ 

05964 #defme TSS3_S_SP0 4 

05965 

05966 /* Funciones exportadas. 

05967 * Nota: en lenguaje ensamblador el enunciado .define aplicado a un nombre de 

05968 * función equivale aprox. a un prototipo en código C -hace posible vincularse 

05969 * con una entidad declarada en el código de ensamblador, pero no crea la 

05970 * entidad. */ 

05971 

05972 #define _idle_task 

05973 #define _restart 

05974 #define save 

05975 

05976 #define _divide_error 

05977 #define _single_step_exception 

05978 #define _nmi 

05979 #define _breakpoint_exception 

05980 #define _overflow 

05981 #define _bounds_check 

05982 #define _inval_opcode 

05983 #define _copr_not_available 

05984 #define _double_fault 

05985 #define _copr_seg_overrun 

05986 #define _inval_tss 

05987 #define _segment_not_present 

05988 #define _stack_exception 

05989 #define _general_protection 

05990 #define _page_fault 

05991 #define _copr_error 

05992 

05993 #define hwintOO /* manejadores para interrupciones de hardware */ 

05994 #define _hwint01 

05995 #define hwint02 

05996 #define hwint03 

05997 #define _hwint04 

05998 #define hwint05 

05999 #define _hwint06 

06000 #define _hwint07 

06001 #define _hwint08 

06002 #define _hwint09 

06003 #define hwint 10 

06004 #define _hwint 11 

06005 #define _hwint 12 

06006 #define _hwint 13 

06007 #define _hwint 14 

06008 #define hwint 15 06009 

06010 #define _s_call 

06011 #define _p_s_call 

06012 #define _level0_call 

06013 

06014 /* Funciones importadas.*/ 
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06015 

06016 extern _cstart 

06017 .extern _main 

06018 .extern ~exception 

06019 .extern _interrupt 

06020 .exterrl _sys_call 

06021 .extern _unhold 

06022 

06023 Variables exportadas. 

06024 Nota: usado con una variable, .define no reserva memoria, hace al nombre 06025 ! visible externamente para que 
posible vincularse a él. 


06026 

06027 

06028 

06029 

06030 

06031 

06032 

06033 

06034 

06035 

06036 

06037 

06038 

06039 

06040 

06041 

06042 

06043 

06044 

06045 

06046 

06047 

06048 = 

06049 

06050 = 

06051 


#defme begbss 
#define begdata 
#define _sizes 

/* Variables importadas.*/ 

.extern _gdt 
.extern _code_base 
.extern _data_base 
.extern _held_head 
.extern _k_reenter 
.extern _pc_at 
.extern _proc_ptr 
.extern _ps_mca 
.extern _tss 
.extern _level 0_func 
.extern _mon_sp 
.extern _mon_retum 
.extern _reboot_code 


/*punto de entrada del kemel de MINEX */ 


06052 

jmp 

over_flags 

/* saltarse unos cuantos bytes */ 

06053 

,data2 CLICK_SHIFT 

/* para el monitor: granularidad de memoria */ 

06054 

flags: 



06055 

.data2 

: 0x002D 

/* banderas del monitor de arranque: */ 

06056 



/* llamar en modo 386, hacer pila,*/ 

06057 



/*cargar alto, retomará */ 

06058 

nop 


/* byte extra para sincronizar desensamblador * 

06059 

over_ 

flags: 


06060 




06061 Preparar marco de pila C £ 

;n pila del monitor. (Monitoi 

• establece es y ds 06062 ! correctamente. El descrip. ss aún se reí 

06063 

movzx esp, sp 

/* pila de monitor es pila de 16 bits*/ 

06064 

push 

ebp 


06065 

mov 

ebp, esp 


06066 

push 

esi 


06067 

push 

edi 


06068 

cmp 

4(ebp), 0 

/* no 0 si es posible el retomo*/ 

06069 

jz 

noret 


06070 

inc 

(_mon_retum) 


06071 

noret: mov 

(_mon_sp), esp 

/* guardar apunto a pila p/regresar luego*/ 

06072 




06073 

/* Copiar tabla de descriptores global del mono en el esp. de dir. del kemel 

06074 

* Y conmutar a 

ella. Así, prot_init() puede actualizar la con efecto inmediato. */ 
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06075 




06076 

sgdt 

(_gdt+GDT SELECTOR) 

/* obtener gdtr de monitor*/ 

06077 

mov 

esi, (_gdt+GDT_SELECTOR+2) 

/* dirección absoluta de GDT */ 

06078 

mov 

ebx, gdt 

/* dirección de GDT de kernel */ 

06079 

mov 

ecx, 8*8 

/* copiar ocho descriptores */ 

06080 

copygdt: 



06081 

eseg movb 

al, (esi) 


06082 

movb 

(ebx), al 


06083 

inc 

esi 


06084 

inc 

ebx 


06085 

loop 

copygdt 


06086 

mov 

eax, (_gdt+DS SELECTOR+2) 

/* base de datos de kemel*/ 

06087 

and 

eax, OxOOFFFFFF 

/* sólo 24 bits */ 

06088 

add 

eax, _gdt 

/* eax = vir2phys(gdt) */ 

06089 

mov 

(_gdt+GDT SELECTOR+2), eax 

/* fijar base de GDT */ 

06090 

19dt 

(_gdt+GDT_SELECTOR) 

/* cambiar a GDT de kemel */ 

06091 




06092 

/* Localizar 

paráms. de arranque, preparar registre 

is de segmento de kemel y pila.*/ 

06093 

mov 

ebx, 8(ebp) /* distancia a 

parámetros arranque */ 

06094 

mov 

edx, 12(ebp) /* longitud de parámetros arranque */ 

06095 

mov 

ax, ds /* datos de kemel */ 

06096 

mov 

es, ax 


06097 

mov 

fs, ax 


06098 

.mov 

gs,ax 


06099 

mov 

ss, ax 


06100 

mov 

esp, k_stktop /* hacer que sp apunte a tope de pila del kemel*/ 

06101 




06102 

/* Llamar código inicio en C p/establecer entorno apropiado para main().*/ 

06103 

push 

edx 


06104 

push 

ebx 


06105 

push 

SS SELECTOR 


06106 

push 

MON CS SELECTOR 


06107 

push 

DS SELECTOR 


06108 

push 

CSSELECTOR 


06109 

cali 

_cstart ! cstart(cs, ds, 

mes, mds, parmoff, parmlen) 

06110 

add 

esp, 6*4 


06111 




06112 

/* Cargar otra ve: 

l gdtr, idtr y registros de segmento en 

la tabla de descriptores*/ 

06113 

/* global t 

¡stablecida por prot_init(). */ 


06114 




06115 

19dt 

(_9dt+GDT SELECTOR) 


06116 

lidt 

(_gdt+I DT_S ELECTOR) 


06117 




06118 

jmpf 

CS_SELECTOR:csinit 


06119 




06120 

016 mov 

ax, DS SELECTOR 


06121 

mov 

ds, ax 


06122 

mov 

es, ax 


06123 

mov 

fs, ax 


06124 

mov 

gs, ax 


06125 

mov 

ss, ax 


06126 

016 mov 

ax, TSS SELECTOR /* i 

tío se usa otro TSS */ 

06127 

ltr 

ax 


06128 

push 

0 / 

'* poner banderas en estado bueno conocido*/ 

06129 

popí 

/* elim. tarea anid. y hábil. Int */ 

06130 




06131 

jmp 

_main /*: 

main()*/ 

06132 




06133 
06134 *= 
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06135 /* manejadores de interrupciones * 

06136 /* manejadores de interrupciones para modo protegido 386 de 32 bits * 

06137 /*======== — ===== —— ======== — - - ================== == = ==== * 

06138 

06139 /♦=== = = == == = ==== = == == == = === ===== ======== == ♦ 

06140 /* hwintOO -07 * 

06141 /*=== = = = == = == = === == ===== = == ==== === ========= = == * 

06142 /* Aunque parece subrutina, ésta es una macro.*/ 

06143 #defme hwint master(irq) 


06144 

cali -save 

/* guardar estado proc. interrumpido *A 

06145 

inb INT CTLMASK 

); 

06146 

orb al,-[l«irq] 

); 

06147 

outb INT CTLMASK 

1 * inhabilitar irq*/ 

06148 

movb al,-ENABLE 

); 

06149 

outb INT CTL 

/* rehabilitar 8259 maestro*/ 

06150 

sti /* habilitar interrupciones*/ 

06151 

push irq 

/* irq*/ 

06152 

cali (irq table + 4*irq) 

/* eax = (*irq_table[irq])(irq)*/ 

06153 

pop ecx -;\ 


06154 

cli 

/* inhabilitar interrupciones*/ 

06155 

test eax, eax 

/* ¿necesario rehabilitar irq? */ 

06156 

jz Of 

); 

06157 

inb INT CTLMASK 

); 

06158 

andb al,—[1 «irq] 

); 

06159 

outb INT CTLMASK 

1 * habilitar irq*/ 

06160 

0: 

ret /* reiniciar (otro) proceso*/ 

06161 



06162 

/*CAJ de estos ptos. de entrada es u 

na expansión de la macro hwint_master*/ 

06163 

align 16 


06164 

_hwint00: /* Rutina de ir 

rt. para irq 0 (el reloj)*/ 

06165 

hwint_master(0) 


06166 



06167 

align 16 


06168 

_hwint01: /* Rutina de ir 

rt. para irq 1 (teclado)*/ 

06169 

hwint_master(l) 


06170 



06171 

align 16 


06172 

_hwint02: /* Rutina de ir 

ít. para irq 2 (icascada!)*/ 

06173 

hwint_master(2) 


06174 



06175 

align 16 


06176 

_hwint03: /* Rutina de ir 

ít. para irq 3 (segundo serial)*/ 

06177 

hwint_master(3) 


06178 



06179 

align 16 


06180 

_hwint04: /* Rutina de ir 

ít. para irq 4 (primer serial)*/ 

06181 

hwint_master(4) 


06182 



06183 

align 16 


06184 

_hwint05: /* Rutina de ir 

ít. para irq 5 (Winchester XT)*/ 

06185 

hwint_master(5) 


06186 



06187 

align 16 


06188 

_hwint06: /* Rutina de ir 

ít. para irq 6 (disquete)*/ 

06189 

hwint_master(6) 


06190 



06191 

align 16 


06192 

_hwint07: /* Rutina de ir 

ít. para irq 7 (impresora)*/ 

06193 

hwint_master(7) 



06194 
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06196 /* 


hwint08 

15 * 





06198 

/* Aunque parece subrutina, ésta es 

ana macro.*/ 


06199 


#define hwint slave(irq) 

06200 

cali save 


/* guardar estado proc. interrumpido */ 

06201 

inb INT2 CTLMASK; 



06202 

orb al, [l«[irq-8]]; 



06203 

outb INT2 CTLMASK 


/* inhabilitar irq*/ 

06204 

movb al, ENA8LE; 



06205 

outb INT CTL 


/* rehabilitar 8259 maestro*/ 

06206 

jmp ,+2 


/* retardo*/ 

06207 

outb INT2 CTL 


/* rehabilitar 8259 esclavo*/ 

06208 

sti 


/* habilitar interrupciones*/ 

06209 

push irq 


/* irq*/ 

06210 

cali ( irq table + 4*irq) 


/* eax = (*irq_table[irq]) (irq)*/ 

06211 

pop ecx 



06212 

cli 


/* inhabilitar interrupciones*/ 

06213 

test eax, eax 


/* ¿necesario rehabilitar irq?*/ 

06214 

jz Of 



06215 

inb INT2 CTLMASK 



06216 

andb al, -[l«[irq-8]] 



06217 

outb INT2 CTLMASK 


/* habilitar irq*/ 

06218 

0: ret 


/* reiniciar (otro) proceso*/ 

06219 




06220 

/* C/u de estos ptas. de entrada es una expansión de la macro hwint slave*/ 

06221 

align 16 



06222 


hwint08: 

/* Rutina de int. para irq 8 (reloj tiempo real)*/ 

06223 

hwint slave(8) 



06224 




06225 

align 16 



06226 


hwint09: 

/* Rutina de int. para irq 9 (irq 2 redirigida)*/ 

06227 

hwint slave(9) 



06228 




06229 

align 16 



06230 


hwint 10: 

/* Rutina de int. para irq 10*/ 

06231 

hwint slave(10) 



06232 




06233 

align 16 



06234 


hwintll: 

/* Rutina de int. para irq 11 */ 

06235 

hwint slave(ll) 



06236 




06237 

align 16 



06238 


hwint 12: 

/* Rutina de int. para irq 12*/ 

06239 

hwint slave(12) 



06240 




06241 

align 16 



06242 


hwintl3: 

/* Rutina de int. para irq 13 (excepción FPU)*/ 

06243 

hwint slave(13) 



06244 




06245 

align 16 



06246 


hwint 14: 

/* Rutina de int. para irq 14 (Winchester AT)*/ 

06247 

hwint slave(14) 



06248 




06249 

align 16 



06250 


hwintl5: 

/* Rutina de int. para irq 15*/ 

06251 

hwint slave(15) 



06252 








06254 


/*save */ 
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06255 

06256 

06257 

06258 

06259 

06260 

06261 

06262 

06263 

06264 

06265 

06266 

06267 

06268 

06269 

06270 

06271 

06272 

06273 

06274 

06275 

06276 

06277 

06278 

06279 

06280 

06281 

06282 

06283 

06284 

06285 

06286 

06287 

06288 

06289 

06290 

06291 

06292 

06293 

06294 

06295 

06296 

06297 

06298 

06299 

06300 

06301 

06302 

06303 

06304 

06305 

06306 

06307 

06308 

06309 

06310 

06311 

06312 

06313 

06314 


/* Save para modo protegido.*/ 


/* Es mucho m 

ás simple que para modo 8086 porque la pila ya apunta a la tabla*/ 

/* de procesos, 

o ya se conmutó a 

la pila del kemel.*/ 

align 

16 


cid 


/* dar valor conocido a bando dirección*/ 

pushad 


/* guardar registros "generales"*/ 

016 push 

ds 

/* guardar ds*/ 

016 push 

es 

/* guardar es*/ 

016 push 

fs 

/* guardar fs*/ 

016 push 

gs 

/* guardar gs*/ 

mov 

dx, ss 

/*ss es segm. de datos de kemel*/ 

mov 

ds, dx 

/*cargar resto de segm. de kemel*/ 

mov 

es, dx 

/*el kemel no usa fs, gs*/ 

mov 

eax, esp 

/*preparar retomo*/ 

incb 

( k reenter) 

/* de -1 si no es reingreso*/ 

jnz 

set_restartl 

/*pila ya es pila del kemel*/ 

mov 

esp, k stktop 


push 

restart 

/* formar dir. de retomo p/manej. ints.*/ 

xor 

ebp, ebp 

/* para rastreo de pila*/ 

jmp 

RETADR-P STACKBASE(eax) 

align 

4 


setrestartl: 

push restartl 



jmp RETADR-P STACKBASE(eax) 



_s_call 


align 16 

_s_oall: 

_p_s_call: 

cid 


/* dar valor conocido a bando dirección*/ 

/* saltar RETADR, eax, ecx, edx, ebx, est*/ 
ebp /* pila ya apunta a tabla de proc.*/ 


016 push 
016push es 

016 push fs 

016 push gs 

mov dx, ss 




_sys_call 
AXREG(esi), < 


/* supone P_STACKBASE 0*/ 

/* para rastreo de pila*/ 

/*fin de save en línea*/ 

/* permitir interrumpir SWITCHER*/ 

/*/prep. paráms. para sys_call()*/ 

/* apuntador a mensaje de usuario*/ 

/* src/dest*/ 

/* SEND/RECEIVE/BOTH*/ 

/* sys_call(function, srcdest, m_ptr)*/ 

/* invocador está explícitamente en proc_ptr*/ 
/* sys cali DEBE CONSERVAR si*/ 
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06315 

06316 

06317 

06318 

06319 

06320 


06323 

06324 

06325 

06326 

06327 

06328 

06329 

06330 

06331 

06332 

06333 

06334 

06335 

06336 

06337 

06338 

06339 

06340 

06341 

06342 

06343 

06344 

06345 

06346 

06347 

06348 

06349 

06350 

06351 

06352 

06353 

06354 

06355 

06356 

06357 

06358 

06359 

06360 

06361 

06362 

06363 

06364 

06365 

06366 

06367 

06368 

06369 

06370 

06371 

06372 

06373 

06374 


cli /* inhabilitar interrupciones*/ 

/* Continuar con el código para reiniciar proc/tarea en ejecución.*/ 


/* Vaciar cualesquier interrupciones detenidas. * 

* Esto rehabilita ints, así que el manejador de ints actual puede reingresar.* 

* No importa, porque el manejador actual va a salir y ningún otro puede * 
/* reingresar, pues el vaciado sólo se hace cuando k reenter == 0. * 


lldt 




popad 


decb 
016 pop 
016 pop 
016 pop 
016 pop 

add 


(_held head), 0 /* prueba rápida p/evitar llamada a función*/ 

over_call_unhold 

unhold /* poco frecuente, así que costo extra aceptable*/ 


esp, Q>roc_ptr) 

P LDT SEL(esp) 

eax, P STACKTOP(esp) 

(_tsS+TSS3_S_SP0), eax 


/* supondrá P STACK8ASE == 0*/ 
/* habilitar descript. segm. p/tarea*/ 
/* prep. p/siguiente interrupción*/ 

/* p/guardar estado en tabla proc.*/ 


(_k_reenter) 

f S 

ds 




/* saltarse dirección de retomo*/ 
/* continuar proceso*/ 


/* manej adores de excepciones 


push DIVIDE VECTOR 

jmp exception 

_single_step_exception: 

push DEBUGVECTOR 

jmp exception 


push NMI VECTOR 

jmp exception 

breakpointexception: 

push BREAKPOINT VECTOR 

jmp exception 


overflow: 

push OVERFLOW VECTOR 

jmp exception 

bounds check: 

push BOUNDS VECTOR 
jmp exception 


inval opcode: 
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06375 push INVAL OP VECTOR 

06376 jmp exception 

06377 

06378 copr_not_available: 

06379 push COPROCNOT VECTOR 

06380 jmp exception 

06381 

06382 doublefault: 

06383 push DOUBLE FAULT VECTOR 

06384 jmp errexception 

06385 

06386 copr seg_overrun: 

06387 push COPROCSEGVECTOR 

06386 jmp exception 

06389 

06390 inval_tss: 

06391 push INVAL TSS VECTOR 

06392 jmp errexception 

06393 

06394 _segment_not_present: 

06395 push SEG_NOT_VECTOR 

06396 jmp errexception 

06397 

06398 _stack_exception: 

06399 push STACK FAULTJVECTOR 

06400 jmp errexception 

06401 

06402 general_protection: 

06403 push PROTECTION VECTOR 

06404 jmp errexception 

06405 

06406 _page_fault: 

06407 push PAGE_FAULT VECTOR 

06408 jmp errexception 

06409 

06410 copr error: 

06411 push COPROC ERR VECTOR 

06412 jmp exception 

06413 

06414/!*==================================================* 

06415 /* exception * 

06416 /*====——= . — - = .. - = == =■.. =♦ 

06417 /* Se invoca para todas las excepciones que no forman pila de un código de error.*/ 

06418 

06419 align 16 

06420 exception: 

06421 sseg mov (trap ermo), 0 /* despejar trap ermo*/ 

06422 sseg pop (exnumber) 

06423 jmp exceptionl 

06424 

06425 /*================================================* 

06426 /* errexception * 

06427 /*===== - = - === - ===== - * 

06428 /* Se invoca para todas las excepciones que forman pila de un código de error.*/ 

06429 

06430 .align 16 

06431 errexception: 

06432 sseg pop (ex number) 

06433 sseg pop (trap ermo) 

06434 exceptionl: /* Común a todas las excepciones.*/ 
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06435 

06436 

06437 

06438 

06439 

06440 . 

06441 

06442 

06443 

06444 

06445 

06446 

06447 

06448 

06449 

06450 

06451 

06452 

06453 

06454 

06455/* 

06456 /• 

06457 /* 

06458 

06459 

06460 

06461 

06462 /*■ 

06463 /' 

06464 /* 

06465 i( 

06466 

06467 

06468 /* 

06469/* 

06470/* 

06471 

06472 

06473 ■ 

06474 

06475 ’ 

06476 / 

06477 

06478 .se 

06479 

06480 

06481 

06482 

06483 .se 


eax, 0+4(esp) 
(oíd eip), eax 
eax, 4+4(esp) 
(oldcs), eax 
eax, 8+4(esp) 
(oldeflags), ea: 


(oldeflags) 

(old_cs) 

(old_eip) 

(trap ermo) 

(ex_number) 

exception (exnumber, trape 


oldcs, old eflags) 


lo hay trabajo*/ 
esto falla en modo prot.*/ 




/* Estas declaraciones aseguran que se asignará memoria al principio * 

* de la sección de datos del kemel, para poder informar fácilmente* 
al monitor de arranque cómo parchar estas posiciones. El compilador * 

* pone aquí el núm. mágico, pero el monitor lo lee y sobreescribe. * 

Al iniciar el kemel el arreglo de tamaños se encontrará aquí, * 

‘ como si hubiera sido inicializado por el compilador. 

;t .rom /* Antes de la tabla de cadenas, por favor*/ 

sizes: /* arranque llena tamo kemel, mm, fs*/ 

-.data2 0x526F /* debe ser la. entrada datos (# mágico)*/ 

.space 16*2*2-2 /* monitor usa palo ant. y este espacio*/ 

/* espacio extra p/servidores adic.*/ 


06484 k stack: 

06485 -.space K STACK BYTES 
06486 k stktop: 


06487 

06488 

06489 

06490 

06491 


.comm ex number, 4 

.corran oíd eip, 4 
.corran old_cs, 4 
.corran old eflags, 4 


/* pila de kemel*/ 

/* tope de pila de kemel*/ 
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06500 /* Este arch. contiene el código de inicio en C para Minix en procesadores 

06501 * Intel; coopera con mpx.s para establo buen entorno para main(). 

06502 * 

06503 * Este código se ejecuta en modo real para un kemel de 16 bits y podría 
06504 * tener que cambiar a modo protegido para un 286. 

06505 * 

06506 * Para un kemel de 32 bits ya ejec. en modo prot., pero los selectores 
06507 * aún son los dados por BIOS con ints. inhabilitadas, así que hay que 
06508 * volver a cargar descriptores y crear descriptores de interrupciones. 

06509 */ 

06510 

06511 #include "kemel.h" 

06512 #include <stdlib.h> 

06513 #include <minix/boot.h> 

06514 #ínclude "protect.h" 

06515 

06516 PRIVATE char k environ[256] ; /* cadenas de entorno que pasa el cargador */ 

06517 

06516 FORWARD PROTOTYPE( int k_atoi, (char *s) ) ; 

06519 

06520 

0652173^4 1 Ü •: 

06522 * cstart 

065fp§É=============================================================== : 

06524 PUBLIC void cstart(cs, ds, mes, mds, parmoff, parmsize) 

06525 U16tcs, ds; /* segm. de código y datos del kemel */ 

06526 U16-t mes, mds; /* segm. de código y datos del monitor */ 

06527 U16=t parmoff, parmsize; /* disto y long. de paráms. de arranque */ 

06528 { 

06529 /* Realizar inicializaciones del sistema antes de invocar main(). */ 

06530 

06531 register char *envp; 

06532 physbytes meodebase, mdatabase; 

06533 unsigned mon start; 

06534 

06535 /* Tomar nota de dónde están el kemel y el monitor. */ 

06536 codebase = seg2phys(cs); 

06537 database = seg2phys(ds); 

06536 meodebase = seg2phys(mcs); 

06539 mdata base = seg2phys(mds); 

06540 

06541 /* Inicializar descriptores de modo protegido. */ 

06542 protJnit(); 

06543 

06544 /* Copiar parámetros de arranque en memoria del kemel. */ 

06545 if (parmsize > sizeof k_environ -2) parmsize = sizeof k environ -2; 

06546 phys_copy(mdata_base + parmoff, vir2phys(k environ) , (phys bytes) parmsize); 

06547 

06548 /* Convertir variables de entorno de arranque importantes. */ 

06549 boot_parameters.bp rootdev = k_atoi(k_getenv("rootdev"»; 

06550 boot_parameters.bp_ramimagedev = k_atoi(k_getenv("ramimagedev"»; 

06551 boot_parameters.bp ramsize = k_atoi(k_getenv("ramsize"» ; 

06552 booVparameters.bp_processor = k atoi(k_getenv("processor"»; 

06553 


/* Tipo de VDU: */ 
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06555 envp = k_getenv("video"); 

06556 if (strcmp(envp, "ega") == 0) ega = TRUE; 

06557 if (strcmp(envp, "vga") WW$) vga = ega = TRUE; 

06558 . 

06559 /* Tamaños de memoria: */ 

06560 low memsize = k atoi(k getenv("memsize">>; 

06561 ext=:memsize = k=:atoi(k=:getenv("emssize"»;j 
06562 

06563 1* ¿Procesador?*/ 

06564 processor = boot_parameters.bp_processor; /* 86, 186,286, 386, ...*/ 

06565 

06566 /* ¿Bus XT, AT o MCA? */ 

06567 envp = k_getenv("bus"); 

06568 if (envp = NIL_PTR :: strcmp(envp, "at") == 0) { 

06569 pc_at = TRUE; 

06570 } else 

06571 if (strcmp(envp, "mea") == 0) { 

06572 pe at = ps mea = TRUE; 

06573 } 

06574 

06575 /* Decidir si el modo es protegido. */ 

06576 #if _WORD_SIZE = 2 
06577 protected mode = processor >= 286; 

06578 #endif 

06579 

06580 /* ¿Hay monitor al cual volver? En tal caso, no arriesgar. */ 

06581 if (Iprotected mode) mon retum = 0; 

06582 mon start = meode base / 1024; 

06583 if (mon retum &&-10w memsize > monstart) low memsize = mon start; 

06584 

06585 /* Volver a código ensamblador para cambiar a modo protegido (si 286), 

06586 * volver a cargar selecto res e invocar main(). 

06587 */ 

06588 } 

06591 /*= . =========== . ====== . ======* 

06592 * k atoi 

06593 * - */ 

06594 PRIVATE int k atoi(s) 

06595 register char *S; 

06596 { 

06597 /* Convertir cadena en entero. */ 

06598 

06599 retum strtol(s, (char **) NULL, 10); 

06600 } 

066 $é* - -* 

06604 * k_getenv 

06605 *====================================================*/ 

06606 PUBLIC char *k_getenv(name) 

06607 char *name; 

06608 { 

06609 /* Obtener valor de entorno -versión del kemel de getenv par evitar 

06610 * crear el arreglo de entorno usual. 

06611 */ 

06612 

06613 register char *namep; 

06614 register char *envp; 
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06615 

06616 for (envp = kenviron; *envp != 0;) { 

06617 for (namep = ñame; *namep != 0 && *namep == *envp; namep++, envp++;) 

06618 

06619 if (*namep == '\0' && *envp = '=') retum(envp + 1); 

06620 while (*envp++ != 0) 

06621 

06622 } 

06623 retum(NIL PTR); 

06624 } 


src/kemel/main. c 


06700 /* Este archivo contiene el programa principal de MINIX. La rutina main() 

06701 * inicializa el sistema y pone la pelota enjuego estableciendo la tabla 
06702 * de procesos, vectores de interrupciones y planificando la ejecución de 
06703 * todas las tareas para que se inicialicen a sí mismas. 

06704 * 

06705 * Las entradas de este archivo son: 

06706 * main: programa principal de MINIX 

06707 * panic: abortar MINIX por error fatal 

06708 */ 

06709 

06710#include "kemel.h" 

06711 #include <signal.h> 06712 #include <unistd.h> 

06713 #include <minix/callnr.h> 

06714 #include <minix/com.h> 

06715 #include "proc.h" 

06716 

06717 

06718 /*=========================================================* 

06719 * main 

06720 *=========================*/ 

06721 PUBLIC void main() 

06722 { 

06723 I* Poner en juego la pelota. */ 

06724 

06725 register struct proc *rp; 

06726 register int t; 

06727 int sizeindex; 

06728 physclicks textbase; 

06729 vir_clicks text_clicks; 

06730 vir_clicks data clicks; 

06731 phys_bytes phys_b; 

06732 reg_t ktsb; /* base de pila de tareas de kemel */ 

06733 struct memory *memp; 

06734 struct tasktab *ttp; 

06735 

06736 /* Oficializar el controlador de interrupciones. */ 

06737 ¡ntrjnit(l); 

06738 

06739 /* Interpretar tamaños de memoria. */ 
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06740 

06741 

06742 

06743 

06744 

06745 

06746 

06747 

06748 

06749 

06750 

06751 

06752 

06753 

06754 

06755 

06756 

06757 

06758 

06759 

06760 

06761 

06762 

06763 

06764 

06765 

06766 

06767 

06768 

06769 

06770 

06771 

06772 

06773 

06774 

06775 

06776 

06777 

06778 

06779 

06780 

06781 

06782 

06783 

06784 

06785 

06786 

06787 

06788 

06789 

06790 

06791 

06792 

06793 

06794 

06795 

06796 

06797 

06798 

06799 


mem_init(); 

/* Despejar la tabla de procesos. 

* Establecer correspondencias para macros proc_addr() y proc numberj). 

.for (rp = BEG PROC ADDR, t = -NR TASKSj rp < END PROC ADDRj ++rp, ++t) { 
rp->p flags = P SLOT FREE; 

rp->p_nr = t; /* núm. proc. de apuntador */ 

(pproc addr + NR_TASKS)[t] = rp; /* apunto a proc. de número */ 

} 

/* Crear entradas de tabla proc. p/tareas y servidores. Las pilas de las tareas 

* de kemel se inicializan a un arreglo en esp. de datos. El monitor agregó 

* las pilas de servidores al segmo de datos, así que el apunto a pila 

* se dirige al final del segm. de datos. Todos los proc. están en memoria 

* baja en el 8086. En el 386 sólo el kemel está en memoria baja, el resto 

* se carga en memoria extendida. 


/* Pilas de tareas. */ 

ktsb = (reg t) tstack; 

for (t = -NR TASKSj t <= LOW USERj ++t) { 

rp = proc_addr(t); -/* ranura de proco de t */ 

ttp = &tasktab[t + NRTASKS]; /* atributos de tarea de t */ 

strcpy(rp->p_name, ttp->name); 
if (t < 0) { 

if (ttp->stksize > 0) { 

rp->p_stguard = (reg_t *) ktsb; 

*rp->p_ stguard = STACK_GUARD; 

} 

ktsb += ttp->stksize; 

rp->p_reg.sp = ktsb; 

textbase = code base » CLICK SHIFT; 

/* todas las tareas están en el kemel */ 

sizeindex = 0; /* Y usan tamaños de kemel plenos */ 

memp = &mem[0] ; /* quitar de este trozo de memoria */ 

} else { 

sizeindex = 2 * t + 2; /* MM, FS, INIT tienen sus tamaños */ 

} 

rp->p_reg.pc = (reg_t) ttp->initial_pc; 

rp->p reg.psw = istaskp(rp) ? INIT_TASK_PSW : INIT PSW; 


text_clicks = sizesjsizeindex]; 

data clicks = sizesjsizeindex + 1]; 

rp->p map[T] ,mem_phys = text base; 

rp->p_map[T] omem len = text clickS; 

rp->p map[D] ,mem_phys = text base + text clicks; 

rp->p map[D] .mem len = data clicks; 

rp->p map[S] .memjhys = text base + text_clicks + data clicks; 

rp->p_map[S] .mem vir = data clicks; /* vacío -pila en datos */ 

text base += text_clicks + data clicks; /* listo p/sigte., si servidor */ 

memp->size -= (text_base -memp->base); 

memp->base = text base; /* memoria ya no libre */ 


if (t >= 0) { 


/* Inicializar apunto a pila de servidores. Bajarlo una palabra 
* para dar a crtso.S algo que usar como "argc". 


rp->p_reg.sp = (rp->p_map[S] .mem vir + 
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06800 

06801 

06802 

06803 

06804 

06805 

06806 

06807 

06808 

06809 

06810 

06811 

06812 

06813 

06814 

06815 

06816 

06817 

06818 

06819 

06820 

06821 

06822 

06823 

06826 


06827 

06828 


rp->p_map[S] .mem_len) « CLICK SHIFT; 

rp->p reg.sp -= sizeof(reg_t); 

} 

#if WORD SIZE == 4 

-1 * Los servidores se cargan en memoria extendida en modo 386. *1 

if(t<0){ 

memp = &mem[l]; 

text_base = 0x100000 » CLICK SHIFT; 

} 

#endif 

if (!isidlehardware(t» lock ready(rp); 1 * IDLE, HARDWARE neveready *1 

rp->p flags = 0; 

alloc_segments(rp); 

} 

proc[NR TASKS+INIT PROC NR] ,p_pid =1,7* INIT tiene pid 1 *1 
bill_ptr = proc addr(IDLE); 1 * tiene que apuntar a algo *i 

lock_pick_proc(); 

1 * Pasar al cód. de ensamblador p/inic. ejecución del proc. actual. *1 
restart(); 

} 




06829 PUBLIC void panic(s,n) 

06830 CONST char *s; 

06831 int n; 

06832 { 

06833 1 * El sistema experimentó un error fatal. Terminar ejecución. 

06834 * Si el pánico se originó en MM o FS, la cadena está vacia 
06835 * Y el FS ya está sincronizado. Si el pánico se originó 
06836 * en el kemel, estamos perdidos. 

06837 *1 

06838 

06839 if (*s != 0) { 

06840 printf("\nKemel panic: %s",s); 

06841 if (n != NO_NUM) printf(" %d", n); 

06842 printf("\n"); 

06843 } 

06844 wreboot(RBT PANIC); 

06845 } 
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06900 

06901 

06902 

06903 

06904 

06905 

06906 

06907 

06908 

06909 

06910 

06911 

06912 

06913 

06914 

06915 

06916 

06917 

06918 

06919 

06920 

06921 

06922 

06923 

06924 

06925 

06926 

06927 

06928 

06929 

06930 

06931 

06932 

06933 

06934 

06935 

06936 

06937 

06938 

06939 

06940 

06941 

06942 

06943 

06944 

06945 

06946 

06947 

06948 

06949 

06950 

06951 

06952 

06953 

06954 


/* Este archivo contiene casi todo el manejo de procesos y mensajes. 

* Tiene dos puntos de entrada desde el exterior: 

* sys_call: invocada cuando un proc. o tarea hace SEND, RECEIVE o SENREC 

* interrupt: invocada por ratinas de int. p/enviar mensaje a una tarea 


* También tiene varios puntos de entrada secundarios: 


* lock ready: 

* lock_unready: 

* lock_sched: 

* lock mini send: 

* lock_pick_proc: 

* unhold: 


poner proc. en una cola de listos p/poder ejecutarse 
quitar proc. de cola de listos 
proc. se ejecutó mucho tiempo; planif. otro 
enviar mensaje (usado por señales de int., etc.) 
escoger proc. p/ejecutar (usado por inicializ. sist.) 
repetir todas las interrupciones detenidas 


#include "kemel.h" 

#include <minix/callnr.h> 

#include <minix/com.h> 

#include "proc.h" 

PRIVATE unsigned char switching; /* no 0 para inhibir interrapt() * 1 

FORWARD PROTOTYPE( int mini_send, (stract proc *caller_ptr, int dest, 
message *m_ptr)); 

FORWARD PROTOTYPE( int mini rec, (stract proc *caller ptr, int src, 
message *m_ptr)) j 

FORWARD PROTOTYPE( void ready, (stract proc *rp) ); 

FORWARD PROTOTYPE( void sched, (void) )j 
FORWARD PROTOTYPE( void unready, (stract proc *rp) ); 

FORWARD PROTOTYPE( void pick proc, (void) ); 


#defíne CopyMess(s,sp,sm,dp,dm) \ 

cp mess(s, (sp) ->p map[D] ,mem_phys, (virbytes)sm, (dp)->p map[D] .memjihys, (vir bytes)dm) 


interrupt 


PUBLIC void interrapt(task) 


{ 

/* Ocurrió interrupción. Planificar la tarea que la maneja, 
register stract proc *rp; / 


i que se iniciará */ 


apunto a entrada de proc. de la tarea *1 


rp = procaddr(task); 

* Si esta llamada competiría con otras funes, de conmut. de procs., 

* ponerla en la cola 'detenidos' que se vaciará en el sigte. restart() 

* no competidor. Las condiciones competidoras son: 

* (1) k reenter = (typeof k reenter) -1: 

* Llamada de nivel de tareas, por lo común de una ratina 

* de int. de salida. Un manej. de ints. podría reingresar a interrapt().; 

* Poco frecuente; no amerita tratamiento especial. )1 

* (2) k reenter > 0: 
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06955 

06956 

06957 

06958 

06959 

06960 

06961 

06962 

06963 

06964 

06965 

06966 

06967 

06968 

06969 

06970 

06971 

06972 

06973 

06974 

06975 

06976 

06977 

06978 

06979 

06980 


* Llamada de manej. de ints. anidado. Un manejo de ints. 

* previo podría estar dentro de interrupt() o sys_call(). 

* (3) switching 1= 0: 

* Una tunco de conmut. de proc. distinta de interrupt() está siendo invocada 

* del nivel de tareas, por lo común sched() de CLOCK. Un manejo 

* de ints. podría invocar interrupt y pasar la prueba k reenter. 

*/ 

if (kreenter != 0 11 switching) { 
lock()i 


if (!rp->p_int_held) { 

rp->p int held = TRUEi 

if (held_head != NIL PROC) 

held tail->p_nextheld = rpi 

held head = rp; 
heldtail = rpi 

rp->p ncxtheld = NIL PROC; 

} 

unlock()i 

} 


/* Si la tarea no espera interrupción, registrar el bloqueo. */ 
if ( (rp->p_flags & (RECEIVING 1 SENDING» 1= RECEIVING ; 

!isrxhardware(rp->p_getfrom)) { 
rp->p int blocked = TRUE; 


06982 } 

06983 

06984 /* El destino está esperando una interrupción. 

06985 * Enviarle mensaje con origen HARDWARE y tipo HARD INT. 

06986 * No puede proporcionarse de forma confiable más información porque los 

06987 * mensajes de interrupción no se ponen en cola. 

06988 */ 

06989 rp->p_messbuf->m_source = HARDWAREi 
06990 rp->p messbuf->m type = HARD INT; 

06991 rp->p_flags &= -RECEIVING; 

06992 rp->p_int_blocked = FALSE; 

06993 

06994 /* Hacer a rp listo y ejecutarlo si otra tarea no se está ejecutando ya. Esto 

06995 * es ready(rp) en-línea para mayor velocidad. 

06996 */ 

06997 if(rdy_head[TASK_Q] 1 = NIL PROC) 

06998 rdy tail[TASK_Q] ->p_nextready = rpi 

06999 else 

07000 proc_ptr = rdy head[TASK_Q] = rp; 

07001 rdy_tail[TASK_Q] = rp; 

07002 rp->p nextready = NIL PROC; 

07003 } 

07005 * - * 

07006 * sys_call 

070|||$|===========================================================================*/ 

07008 PUBLIC int sys call(function, src dest, m__ptr); 

07009 int fúnction; /* SEND, RECEIVE o BOTH */ 

07010 int src dest; /* origen del cual recibir o dest. p/enviar */ 

07011 message *m_ptr; /* apuntador a mensaje */ 

07012 { 

07013 /* Las únicas llamadas al sist. en MINIX son enviar y recibir mensajes, 

07014 * Y se efectúan entrando por trampa al kemel con una instrucción INT. 
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07015 * La trampa se atrapa y se invoca sys_call() p/enviar o recibir un mensaje 
07016 * (o ambas cosas). Proc_ptr siempre indica quién llama. 

07017 */ 

07018 

07019 register struct proc *rp; 

07020 intn; 

07021 

07022 1 * Detectar parámetros de llamada al sistema erróneos. * 1 

07023 if(!isoksrc_dest(src dest» retum(EBADSRC); 

07024 rp = proc_ptr; 

07025 

07026 if (isuserp(rp) && function 1= BOTH) retum(E_NO_PERM); 

07027 

07028 1 * Los parámetros están bien, efectuar llamada. * 1 

07029 if (function & SEND) { 

07030 1 * Function = SEND o BOTH. */ 

07031 n = mini_send(rp, src dest, m_ptr)j 

07032 if (function == SEND 11 n 1 = OK) 

07033 retum(n); /* hecho, o falló SEND *1 

07034 } 

07035 

07036 /* Function = RECEIVE o BOTH. 

07037 * Comprobamos que las llamadas de usuario son 80TH, y confiamos en 'function' por lo demás. 

07038 */ 

07039 retum(rmm_rec(rp, src dest, m_ptr»j 
07040 } 

07042 1*==========================================================* 

07043 * mini send : 

0704|jil - *1 

07045 PRIVATE int mini send(caller_ptr, dest, m_ptr) 

07046 register struct proc *caller_ptr; * ¿quién trata de enviar mensaje? * 

07047 int dest; /* ¿a quién se envía mensaje? * 

07048 message *m_ptr; /* apunto a buffer de mensaje * 

07049 { 

07050 /* Enviar mensaje de 'caller__ptr' a 'dest'. Si 'dest' está bloqueado 

07051 * esperando este mensaje, copiarlo en él y desbloquear 'dest'. Si 'dest' 

07052 * no espera, o espera otro origen, formar en cola ’caller ptr'. 

07053 * 

07054 

07055 register struct proc *dest_ptr, *next_ptr; 

07056 vir_bytes vb; /* apunto a bufo mensaje como vir bytes *1 

07057 vir_clicks vio, vhi; /* clics virtuales con mensaje por enviar °1 

07058 

07059 * Procs. de usuario sólo pueden enviar a FS y MM. Comprobar esto. * 

07060 if (isuserp(caller_ptr) && !issysentn(dest» retum(E_BAD_DEST); 

07061 dest_ptr = proc addr(dest)j /* apunto a entrada de proc. de dest. °1 

07062 if (dest_ptr->p flags & P SLOT_FREE) retum(E BAD DEST); I o dest. muerto *1 

07063 

07064 * Esta prueba permite que el mensaje esté en datos, pila o espacio 

07065 * intermedio. Tendrá que hacerse más completa en máquinas 

07066 * que no tienen el espacio mapeado. 

07067 * 

07068 vb = (vir_bytes) m_ptr; 

07069 vio = vb » CLICK SHIFT; 1 * clic viro para base de mensaje * 1 

07070 vhi = (vb + MESS_SIZE -1) »CLICK SHIFTj 1* clic viro para tope de mensaje 

07071 if (vio < callerj)tr->p_map[D] ,mem_vir 11 vIo> vhi 11 

07072 vhi >= caller_ptr->p map[S] .mem vir + caller_ptr->p_map[S] .memlen) 

07073 retum(EFAULT); 

07074 
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07075 

07076 

07077 

07078 

07079 


07082 

07083 

07084 

07085 

07086 

07087 

07088 

07089 

07090 

07091 

07092 

07093 

07094 

07095 

07096 

07097 

07098 

07099 

07100 

07101 

07102 

07103 

07104 

07105 

07106 

07107 

07108 

07109 

07110 

07111 

07112 

07113 

07114 


/* Detectar bloq. mortal si 'caller_ptr' y 'dest' se envían mutuamente. */ 
if (dest_ptr->p_flags & SENDING) { 

nextjrtr = proc_addr(dest_ptr->p_sendto); 
while (TRUE) { 

if (next_ptr = caller_ptr) retum(ELOCKED); 
if (next_ptr->p_flags & SENDING) 

next_ptr = proc_addr(next_ptr->p sendto); 


} 


/* Ver si 'dest' está bloqueado esperando este mensaje. */ 
if ((dest_ptr->p_flags & (RECEIVING 1 SENDING)) == RECEIVING && 
(dest_ptr->p_getfrom = ANY 11 
dest_ptr->p_getfrom = proc number(caller_ptr))) { 

/* El destino sí está esperando este mensaje. */ 

CopYMeSSjproc number(caller_ptr), caller_ptr, m_ptr, dest_ptr, 
dest_ptr->p_messbuf); 


/* desbloquear destino */ 


dest_ptr->p_flags &= -RECEIVING; 
if (dest_ptr->p_flags — 0) ready(dest_ptr); 

{ 

/* El destino no espera. Bloqueo y formo en cola invocador. */ 
caller_ptr->p messbuf= m_ptr; 
if (callerj>tr->p_flags == 0) unready(callerj)tr); 
caller_ptr->p flags 1= SENDING; 
caller_ptr->p_sendto= destj 

/* Proceso bloqueado ya. Ponerlo en la cola del destino. */ 
if ((next ptr = dest_ptr->p callerq) = NIL PROC) 
dest_ptr->p_callerq = caller_ptr; 

else { 

while (next_ptr->p_sendlink 1= NIL PROC) 

next_ptr = next_ptr->p sendlink; 
next_ptr->p sendlink = caller_ptr; 

} 

caller_ptr->p sendlink = NIL PROC; 

} 

retum(OK); 

} 


07119 PRIVATE int mini_rec(caller_ptr, src, m_ptr) 

07120register struct proc *caller_ptr; /* proc. trata de obtener mensaje */ 

07121 int src; /* origen de mens. deseado (o ANY) */ 

07122message *m_ptr; /* apunto a buffer de mensaje */ 

07123 { 

07124 /* Un proceso o tarea quiere obtener un mensaje. Si hay uno en cola, 

07125 * adquirirlo y desbloquear emisor. Si no hay mensaje del origen deseado, 

07126 * bloquear invocador. No hay que comprobar validez de paráms. Las llamadas 
07127 * de usuario siempre son sendrec(), y mini_send() ya comprobó. Se Confía 
07128 * en las llamadas de las tareas, MM y FS. 


07129 */ 

07130 

07131 registerst 


;t proc *senderj>tr; 

;t proc *previous_ptr; 


/* Ver si ya está disponible un mensaje del origen deseado. */ 
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07135 if (1 (caller_ptr->p_flags & SENDING)) { 

07136 1 * Verificar cola de invocador. *1 

07137 for (sender_ptr = caller_ptr->p_callerqj sender_ptr != NIL_PROC; 

07138 previousjtr = sender_ptr, sender_ptr = senderj)tr->p sendlink) { 

07139 if (src == ANY 11 src == proc number(sender jptr)) { 

07140 1 * Se encontró un mensaje aceptable. *1 

07141 CopyMess(proc number(sender_ptr), senderjttr, 

07142 sender_ptr->p_messbuf, caller_ptr, m_ptr); 

07143 if (sender_ptr = caller_ptr->p_callerq) 

07144 caller_ptr->p callerq = sender_ptr->p sendlink; 

07145 else 

07146 previous_ptr->p_sendlink = sender_ptr->p_sendlink; 

07147 if «sender_ptr->p_flags &= -SENDING) == 0) 

07148 ready(sender_ptr); 1 * desbloquear emisor *1 

07149 retum(OK); 

07150 } 

07151 } 

07152 

07153 1 * Detectar interrupción bloqueada. *1 

07154 if (caller_ptr->p_int_blocked && isrxhardware(src)) { 

07155 m_ptr->m source = HARDWARE; 

07156 m_ptr->m_type = HARD INT; 

07157 caller_ptr->p_int_blocked = FALSE; 

07158 retum(OK); 

07159 } 

07160 } 

07161 

07162 1* No hay mensaje adecuado. Bloquear el proc. que intenta recibir. *1 

07163 callerjttr->p getfrom = src; 

07164 caller_ptr->p messbuf = m_ptr; 

07165 if (caller_ptr->p_flags — 0) unready(caller_ptr); 

07166 caller_ptr->p flags 1= RECEIVING; 

07167 

07168 1 * Si MM acaba de bloquearse y hay señales de kemel pendientes, 

07169 * es el momento de informar de ellas al MM, pues podrá aceptar el mensaje. 

07170 *1 

07171 if (sig_procs > 0 && proc number(caller_ptr) = MM PROC NR && src == ANY) 

07172 inform(); 

07173 retum(OK); 

07174 } 

07176 7*=============================================================== 

07177 * pick_proc 

07178 *================================================================ 

07179 PRIVATE void pick_proc() 

07180 { 

07181 1* Decidir a quién ejecutar ahora. Se escoge un nuevo proceso fijando 'proc j>tr'. 

07182 * Si se escoge un proc. de usuario nuevo (u ocioso), asentar lo en 'bill_ptr' 

07183 * para que la tarea de reloj sepa a quién cobrar tiempo de sistema. 

07184 *1 

07185 

07186 register struct proc *rp; 1 * proceso por ejecutar *1 

07187 

07188 if ( (rp = rdy_head[TASK_Q]) 1= NILJ>ROC) { 

07189 proc_ptr = rp; 

07190 retum; 

07191 } 

07192 if ( (rp = rdy head[SERVER Q]) 1 = NIL PROC) { 

07193 proc_ptr = rp; 
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07195 

07196 

07197 

07198 

07199 

07200 

07201 

07202 

07203 

07204 

07205 

07207 

07208 

07209 

07210 

07211 

07212 

07213 

07214 

07215 

07216 

07217 

07218 

07219 

07220 

07221 

07222 

07223 

07224 

07225 

07226 

07227 

07228 

07229 

07230 

07231 

07232 

07233 

07234 

07235 

07236 

07237 

07238 

07239 

07240 

07241 

07242 

07243 

07244 

07245 

07246 

07247 

07248 

07249 

07250 

07251 

07252 

07253 


} 

if ( (rp = rdy_head[USER_Q]) 1= NIL PROC) { 
procjtr = rp; 
bill_ptr = rp; 


} 

/* Nadie está listo. Ejecutar tarea ociosa. Esta podría hacerse tarea 
* de usuario siempre lista para evitar este caso especial. 

bill_ptr = procjtr = proc addr(IDLE); 

} 




PRIVATE voidready(rp) 

register struct proc *rp; /* este proc. ya es ejecutable */ 

{ 

/* Añadir 'rp' al final de una de las colas de procesos ejecutables. 

* Se mantienen tres colas: 

* TASK_Q (más alta prioridad) para tareas ejecutables 

* SERVER Q -(prioridad media) sólo para MM y FS 

* USER Q -(más baja prioridad) para procs. de usuario 


if (istaskp(rp)) { 

if (rdy head[TASK_Q] !=NIL_PROC) 

/* Agregar al final de cola no vacía. */ 
rdy tail[TASK_Q] ->p_nextready = rp; 

else { 

procjitr = 

rdy head[TASK_Q] = rp; 

} 

rdy_tail[TASK_Q] = rp; 
rp->p nextready = NIL PROC; 


/* ejecutar tarea i 
/* agregar a cola 


/* nueva entrada 


no tiene sucesor */ 


} 

if (lisuserp(rp)) { /* las demás son similares */ 

if (rdy head[SERVER Q] != NIL PROC) 

rdy tail[SERVER_Q] ->p nextready = rp; 

rdy head[SERVER_Q] = rp; 
rdyJailfSERVER Q] = rp; 
rp.>p_nextready = NILPROC; 

} 

if (rdy head[USER Q] == NIL PROC) 
rdy_tail[USER Q] = rp; 
rp->p nextready = rdy_head[USER_Q]; 
rdy head[USER Q] = rp; 

if (rdy head[USLR Q] !=NIL_PROC) 

rdy tail[USER Q] ->p_nextready = rp; 

else 

rdy_head[USER Q] = rp; 
rdy_tail[USER_Q] = rp; 
rp->p nextready = NIL PROC; 


} 
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07255 /*====================================================== 

07256 * unready 

07258PRTVATE void unready(rp) 

07259 register struct proc *rp; /* este proc. ya no es ejecutable */ 

07260 { 

07261 {* Un proceso se bloqueó. */ 

07262 

07263 register struct proc *xp; 

07264 register struct proc k*qtail; /* TASK Q, SERVERQ o USER_Q rdyjail 

07265 

07266 if (istaskp(rp» { 

07267 /* ¿pila de tareas aún ok? *1 

07268 if (*rp->p_stguard != STACK_GUARD) 

07269 panic("stack overrun by task", proc_number(rp»; 

07270 

07271 if ( (xp = rdy head[TASK_Q]) = NIL PROC) retum; 

07272 if (xp == rp) { 

07273 /* Quitar cabeza de la cola */ 

07274 rdy head[TASK Q] = xp->p nextready; 

07275 if (rp == proc_ptr) pick_proc(); 

07276 retum; 

07277 } 

07278 qtail = &rdy_tail[TASK_Q]; 

07279 } 

07280 else if (!isuserp(rp» { 

07281 if ( (xp = rdy_head[SERVER_Q]) = NIL_PROC) retum; 

07282 if (xp = rp) { 

07283 rdy head[SERVER_Q] = xp->p nextready; 

07284 pick_proc(); 

07285 retum; 

07286 } 

07287 qtail = &rdy tail[SERVER Q]; 

07288 } else 

07289 { 

07290 if ( (xp = rdy head[USER Q]) = NIL_PROC) retum; 

07291 if (xp == rp) { 

07292 rdy_head[USER_Q] = xp->p_nextready; 

07293 pick_proc(); 

07294 retum; 

07295 } 

07296 qtail = &rdyJail[USERJ2]; 

07297 } 

07298 

07299 /* Examinar cuerpo de la cola. Puede hacerse que un proc. no esté listo 

07300 * aunque no se esté ejecutando enviándole una señal que lo termine. 

07301 */ 

07302 while (xp->p_nextready != rp) 

07303 if ((xp = xp->p nextready) == NIL_PROC) retum; 

07304 xp->p_nextready = xp->p_nextready->p nextready; 

07305 if (*qtail == rp) *qtail = xp; 

07306 } 

07308/*======================================================================== 

07309 * sched 

07310 *============================================================ 

07311 PRIVATE void sched() 

07312 { 

07313 /* El proc. actual se ejecutó demasiado tiempo. Si otro proc. de baja prioridad 

07314 * (usuario) es ejecutable, colocar el actual al final de la cola de usuario, 








EL CÓDIGO FUENTE DE MINIX Archivo: src/kemel/proc.c 

07315 * tal vez promoviendo otro usuario a la cabeza de la cola. 

07316 * 

07317 

07318 if (rdy_head[USER_Q] = NIL PROC) retum; 

07319 

07320 * Uno o más procs. de usuario en cola. * 

07321 rdy tail[US~R_Q]->p_nextready = rdy_head[USER_Q]; 

07322 rdy tail[USER Q] = rdy head[USER Q]; 

07323 rdy_head[USER Q] = rdy head[USER Q] ->p nextreadYj 
07324 rdy tail[USER_Q] ->p nextready = NIL PROC; 

07325 pick_proc(); 

07326 } 

073|j|$4==========================================================================* 

07329 * lockminisend * 

07330*^®^=================»|5irfíí||i§#ív==================================*/ 

07331 PUBLIC int lock mini send(caller_ptr, dest, m_ptr); 

07332struct proc *caller_ptij * ¿quién trata de enviar mensaje? * 

07333int dest; * ¿a quién se envía el mensaje? * 

07334message *m_ptr; * apuntador al buffer de mensaje * 

07335 { 

07336* Entrada segura a mini_send() para tareas. *j 
07337 

07338 int resultj 
07339 

07340 switching = TRUE; 

07341 result = mini_send(caller_ptr, dest, m_ptr); 

07342 switching = FALSE; 

07343 retum(result)j 
07344 } 

07346 /*======================================================* 

07347 * lock_pick_proc * 


07349PUBLIC void lock_pick_proc() 

07350 { 

07351 * Entrada segura a pick_proc() para tareas. * 

07352 

07353 switching = TRUE; 

07354 pick_proc(); 

07355 switching = FALSE; 

07356 } 

07358 * 

07359 * lock ready 

07360*=^================================^f*========= 

07361 PUBLIC void lock ready(rp) 

07362struct proc *rp;- * este proceso ya es ejecutable * 

07363 { 

07364* Entrada segura a ready() para tareas. * 

07365 

07366 switching = TRUE; 

07367 ready(rp)j 

07368 switching = FALSE; 

07369 } 

07372 *=—====—===—======— 

07373 * lockunready 

07374*=============================================== 
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07375 PUBLIC void lock unready(rp) 

07376 struct proc *rp; /* este proc. ya no es ejecutable */ 

07377 { 

07378 /* Entrada segura a unready() para tareas. */ 

07379 

07380 switching = TRUE; 

07381 unready(rp); 

07382 switching = FALSE; 

07383 } 

07385 /*================ — . = . = 

07386 * lock sched 

073||P|===================================================================== 

073 88 PUBLIC void lock sched() 

07389 { 

07390 /* Entrada segura a sched() para tareas. */ 

07391 

07392 switching = TRUE; 

07393 schedO; 

07394 switching = FALSE; 

07395 } 

07397 /*========—===—====—======= 

07398 * unhold 

07399 *=======================— 

07400 PUBLIC void unhold() 

07401 { 

07402 /* Vaciar ints. detenidas, k reenter debe ser 0. held head no debe ser 

07403 * NIL PROC. Las ints. deben-estar inhabilitadas. Se habilitarán 

07404 * pero cuando éstas regresen se inhabilitarán. 

07405 */ 

07406 

07407 register struct proc *rp; /* cabeza actual de cola de detenidas */ 

07408 

07409 if (switching) retum; 

07410 rp = held head; 

07411 do { 

07412 if ( (held head = rp->p nextheld) == NIL PROC) held tail = NILPROC; 

07413 rp->p_int_held = FALSE; 

07414 unlockO; /* reducir latenciaj ¡cola detenidas podría cambiar!*/ 

07415 interrupt(proc number(rp»; 

07416 lock(); /* proteger otra vez cola de detenidas */ 

07417 } 

07418 while ( (rp = heldJiead) 1 = NIL PROC); 

07419 } 










EL CÓDIGO FUENTE DE MINIX 


Archivo: src/kemel/cxception.c 


613 


src/kemel/exception.c 


07500 /* Este archivo contiene un manejador de excepciones sencillo. Las excepciones 

07501 * en procesos de usuario se convierten en señales. Las excepciones en el kemel, 

07502 * MM Y FS causan pánico. 

07503 */ 

07504 

07505 #include "kemel.h" 

07506 #include <signal.h> 

07507 #include "proc.h" 

07508 

07509 /*======================= 


07516 

07517 struct ex_s { 

07518 char *msg; 

07519 intsignum; 

07520 int minprocessor; 

07521 }; 

07522 static struct ex_s ex_datar] = { 

07523 "Divide error", SIGFPE, 86, 

07524 "Debug exception", SIGTRAP, 86, 

07525 "Nonmaskable interrupt", SIGBUS, 86, 

07526 "Breakpoint", SIGEMT, 86, 

07527 "Overflow", SIGFPE, 86, 

07528 "Bounds check", SIGFPE, 186, 

07529 "Invalid opcode", SIGILL, 186, 

07530 "Coprocessor not available", SIGFPE, 186, 

07531 "Double fault", SIGBUS, 286, 

07532 "Copressor segment overrun", SIGSEGV, 286 

07533 "Invalid TSS", SIGSEGV, 286, 

07534 "Segment not present", SIGSEGV, 286, 

07535 "Stack exception", SIGSEGV, 286, 

07536 "General protection", SIGSEGV, 286, 

07537 "page fault", SIGSEGV, 386, 

07538 NIL PTR, SIGILL, 0, 

07539 "Coprocessor error", SIGFPE, 386, 

07540 }; 

07541 register struct ex_s *ep; 

07542 struct proc *saved_pro; 

07543 

07544 saved_proc= proc_ptr; /* Guardar proc_ptr, porque podría modificarse 
07545 * por las instrucciones de depuración. 

07546 */ 

07547 

07548 ep = &ex_data[vecnr] ; 

07549 

07550 if (vec_nr «=* 2) { /* NMI espuria en algunas máquinas */ 

07551 printf("got spurious NMI\n"); 

07552 retum; 

07553 } 

07554 


/* ya se usó STACK FAULT */ 

/* quizá trampa de software */ 


07510 * exception 

07511 *========—==—===— 

07512 PUBLIC void exception(vec_nr) 

07513 unsigned vecnrj 

07514 { 

07515 /* Ocurrió excepción o interrupción inesperada. */ 
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07555 if (k_reenter = 0 && isuserp(saved_proc)) { 

07556 unlock(); /* ésta se protege como sys_call() */ 

07557 cause_sig(prOc_number(saved_proc), ep->signum); 

07558 retum; 

07559 } 

07560 

07561 ./* No se supone que esto suceda. */ 

07562 if (ep->msg == NIL PTR 11 processor < ep->minprocessor) 

07563 printf("\nlntel-reserved exception %d\n", vec_nr); 

07564 else 

07565 printf("\n%s\n", ep->msg); 

07566 printf("process number %d, pe = 0x%04x:0x%08x\n", 

07567 proc number(saved proc), 

07568 (unsigned) saved_proc->p_reg.cs, 

07569 (unsigned) saved_proc->p_reg.pc); 

07570 panic("exception in System code", NO_NUM); 

07571 } 


src/kemel/i8259.c 


07600 / * Este arch. contiene rutinas para inicializar el cont. de ints. 8259: 

07601 * get irq^handler: dirección de manej ador para interrupción dada 

07602 * put irq_handler: registrar un manejador de interrupciones 

07603 * intr init: inicial izar el o los controladores de interrupciones 

07604 */ 

07605 

07606 #include "kemel.h" 

07607 

07608 #defme ICW1 AT 
07609 #defme ICW1-PC 
07610 #define ICW1-PS 
07611 #define ICW4-AT 
07612 #defme ICW4=PC 
07613 

07614 FORWARD PROTOTYPE( int spurious irq, (int irq) ); 

07615 

07616 #define set_vec(nr, addr) ((void)0) /* kluge para modo protegido */ 

07617 

076Íl#^4 ¿..f 

07619 * intr_init 

07620 * 

07621 PUBLIC void intrJnit(mine) 

07622 int mine; 

07623 { 

07624 /* Inicializar los 8259, terminando con todas ints. inhabilitadas. 

07625 * Esto sólo se hace en modo protegido; en modo real no tocamos los 8259, 

07626 * sino que usamos las posiciones de BIOS. Se iza "mine" si los 8259 

07627 * se programarán para Minix o se restablecerán a lo que el BIOS espera. 

07628 */ 

07629 

07630 int i; 

07631 

07632 lock(); 

07633 /* Las AT y PS/2 más nuevas tienen dos controladores de ints., un maestro 

07634 * Y un esclavo en IRQ2. (No tenemos que ocupamos de la PC que 


0x11 /* disparado p/flanco, cascada, nec. ICW4 *1 

0x13 /* disp. p/flanco, no cascada, nec. ICW4 */ 

0x19 /* disp. p/nivel, cascada, nec. ICW4 */ 

0x01 /* no SFNM, no buffer, EOI normal, 8086 */ 

0x09 /* no SFNM, buffer, EOI normal, 8086 */ 
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07635 * sólo tiene un controlador, porque debe ejecutarse en modo real.) 

07636 */ 

07637 out byteONT CTL, ps_mca? ICWIPS : ICW1_AT); 

07638 out byte(INT CTLMASK, mine? IRQO VECTOR : BIOS IRQO VEC); 

07639 /* ICW2 para maestro */ 

07640 out byte (INT CTLMASK, (1 « CASCADE IRQ)); /* ICW3 informa a esclavos */ 

07641 out bytefINT CTLMASK, ICW4 AT); 

07642 out byte (INT CTLMASK, -(1 «CASCADEJRQ)); /* máscara IRQ 0-7 */ 

07643 out_byte(INT2_CTL, ps mea? ICWI PS : ICW1AT); 

07644 out byte (INT2 CTLMASK, mine? IRQ8 VECTOR : BIOS IRQ8JVEC); 

07645 /* ICW2 para esclavo */ 

07646 out byte (INT2 CTLMASK, CASCADE IRQ); /* ICW3 es nr esclavo */ 

07647 out byte (INT2_CTLMASK, ICW4_AT); 

07648 oujbyte (INT2_CTLMASK, -0); /* máscara IRQ 8-15 */ 

07649 

07650 /* Inicializar tabla de manejadores de interrupciones. */ 

07651 for (i = 0; i < NR IRQ_VECTORS; /1 ••) irq_table[i] = spurious irq; 

07652 } 

076^^1=========================================================================* 

07655 * spurious irq 

07656 *=======================================================*/ 

07657 PRIVATE int spurious irq(irq) 

07658 int irq; 

07659 { 

07660 /* Manejador de interrupciones por omisión. Se queja mucho. */ 

07661 

07662 if (irq < 0 11 irq >= NR IRQ VECTORS) 

07663 panic("invalid cali to spuriousjrq", irq); 

07664 

07665 printf("spurious irq %d\n", irq). 

07666 

07667 retum (1); /* Rehabilitar interrupción */ 

07668 } 

07670 /*========== - === - * 

07671 * put ircL_handler 

()- ( ,T 3 —---- ----- ^ ^- -L . —. .. > --* > 

07673 PUBLIC void putjrq_handler(irq, handler) 

07674 int irq; 

07675 irqjiandler t handler; 

07676 { 

07677 /* Registrar un manejador de interrupciones. */ 

07678 

07679 if (irq < 0 11 irq >= NR IRQJVECTORS) 

07680 pamc( "mvalid cali to put irqjiandler", irq); 

07681 

07682 if (irq_table[irq] = handler) 

07683 retum; /* inicialización extra */ 

07684 

07685 if (irqjable[irq] != spurious irq) 

07686 panic("attempt to register second irq handler for irq", irq)j 

07687 

07688 disablejrq(irq); 

07689 if (¡protected mode) set veC(BIOS VECTOR(irq), irq_vec[irq]); 

07690 irq_table[irq]= handler; 

07691 irq_use 1= 1 «irq; 

07692 } 
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07700 

07701 

07702 

07703 

07704 

07705 

07706 

07707 

07708 

07709 

07710 

07711 

07712 

07713 

07714 

07715 

07716 

07717 

07718 

07719 

07720 

07721 

07722 

07723 

07724 

07725 

07726 

07727 

07728 

07729 

07730 

07731 

07732 

07733 

07734 

07735 

07736 

07737 

07738 

07739 

07740 

07741 

07742 

07743 

07744 

07745 

07746 

07747 

07748 

07749 

07750 

07751 

07752 

07753 

07754 


src/kemel/protect. c 


/* Este archivo contiene código para inicializar el modo protegido, 

* los descriptores de segmentos de código y de datos, y los descriptores 
'* globales para los descriptores locales en la tabla de procesos. 


#include "kemel.h" 

#include "proc.h" 

#include "protect.h" 

#defme INT GATE TYPE (INT 286 CATE I DESC_386 BIT) 

#defme TSS TYPE (AVL 286 TSS I DESC 386 BIT) 

struct desctableptr s { 

char limit[sizeof(ul6 t)]; 

char base[sizeof(u32_t)]; /* realmente u24t + pad para 286 */ 

}; 

struct gatedesc s { 
ul6t offset_low; 
ul6t selector; 
u8 t pad; 
u8 t pdpltype; 
ul6t offset high 
}; 


/ * 1000YXXXXXI ig & trpg, IXXXXXXXXI task 9 * / 
/* IPIDLI0ITYPE\ */ 


reg t backlink; 

reg_t spO; I* apunto a pila para usar durante interrupción */ 

reg t ssO; /* segmento de pila que usar durante interrupción */ 

regtspl; 

reg_t ssl; 

regt sp2; 

reg_t ss2; 

regj ip; 
regt flags; 
regj ax; 
regj ex; 
reg_t dx; 
reg_t bx; 
regj sp; 
reg t bp; 
regj si; 
regj di; 
regj es; 
regj es; 
regj ss; 
regj ds; 
regj fs; 
regj gs; 
regj ldt; 

ul6 ttrap; 

U; Jio ase, 
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07755 PUBLIC struct segdesc_s gdt[GDT SIZE] ; 

07756 PRIVATE struct gatedescs idt[IDT SIZE]; /* init cero, así que no hay */ 

07757 PUBLIC struct tss_s tSSj /* init cero */ 

07758 

07759 FORWARD PROTOTYPE( void int_gate, (unsigned vecnr, physbytes base, 

07760 unsigned dpltype)); 

07761 FORWARD PRQTOTYPE( void sdesc, (struct segdesc s *segdp, phys bytes base, 

07762 phys bytes size) ); 

07763 

07764/*====================================================== 

07765 * prot_init 

077f|pjji==================================================== 

07767 PUBLIC void prot init() 

07768 { 

07769 /* Establecer tablas para modo protegido. 

07770 * Todas las ranuras GDT están alojadas en tiempo de compilación. 

07771 */ 

07772 

07773 physbytes codebytes; 

07774 physbytes data_bytes; 

07775 struct gate table s *gtp; 

07776 struct desctableptr s *dtp; 

07777 unsigned ldtselector; 

07778 register struct proc *rp; 

07779 

07780 static struct gatetables { 

07781 PROTOTYPE( void (*gate), (void) ); 

07782 unsigned char vec_nr; 

07783 unsigned char privilege; 

07784 } 

07785 gate_table[]: { 

07786 divide error, DIVIDE VECTOR, INTR PRIVILEGE. 

07787 single_step_exception, DEBUG VECTOR, INTR PRIVILEGE, 

07788 nmi, NMI VECTOR, INTR PRIVILEGE, 

07789 breakpoint exception, BREAKPOINT VECTOR, USER PRIVILEGE, 

07790 overílow, OVERFLOW VECTOR, USER_PRIVILEGE, 

07791 bounds check, BOUNDS_VECTOR, INTR PRIVILEGE, 

07792 inval opcode, INVAL OP VECTOR, INTR PRIVILEGE, 

07793 copr_not_available, COPROC_NOT VECTOR, INTR PRIVILEGE, 

07794 double fault, DOUBLE FAULTVECTOR, INTR PRIVILEGE, 

07795 copr seg overrun, COPROC _SEG VLCTOR, INTR PRIVILEGE, 

07796 invaljss, 1 NVAL_TSS_VECTOR, INTR PRIVILEGE, 

07797 segment not present, SLG NOT VECTOR, INTR PRIVILEGE, 

07798 stack exception, STACK FAULT VECTOR, INTR PRIVILEGE, 

07799 general_protection, PROTECTION VECTOR, INTR PRIVILEGE, 

07800 page fault, PAGE FAULT VECTOR, INTR PRIVILEGE, 

07801 copr error, COPROC_ERR_VECTOR, INTR PRIVILEGE, 

07802 { hwintOO, VECTOR( 0), INTR PRIVILEGE }; 

07803 { hwintOl, VECTOR( 1), INTR PRIVILEGE }; 

07804 { hwint02, VECTOR( 2), INTR PRIVILEGE }; 

07805 { hwint03 , VECTOR( 3), INTR PRIVILEGE ;, 

07806 { hwint04, VECTOR( 4), INTR PRIVILEGE }; 

07807 { hwint05, VECTOR( 5), INTR PRIVILEGE }; 

07808 { hwint06, VECTOR( 6), INTR PRIVILEGE }; 

07809 { hwint07, VECTOR( 7), INTR PRIVILEGE }; 

07810 { hwint08, VECTOR( 8), INTR PRIVILEGE }; 

07811 { hwint09, VECTOR( 9), INTR PRIVILEGE }; 

07812 { hwintlO, VECTOR(IO), INTR PRIVILEGE }; 

07813 { hwintl 1, VECTOR(l 1), INTR PRIVILEGE }; 

07814 { hwintl2, VECTOR(12), INTR PRIVILEGE }; 
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07815 { hwintl3, VECTOR(13), INTR PRIVILEGE }; 

07816 { hwintl4, VECTOR(14), INTR PRIVILEGE }; 

07817 { hwintl5, VECTOR(15), INTR PRIVILEGE }; 

07818 }; 

07819 

07820 /* Esta se invoca temprano y no puede usar tablas creadas por main(). */ 

07821 data bytes = (physjytes) sizes[ 1 ] « CLICK SHIFT; 

07822 if (sizes[0] = 0) 

07823 codejiytes = data_bytes; /* I&D común */ 

07824 else 

07825 codebytes = (physjytes) sizes[0]« CLICK SHIFT; 

07826 

07827 /* Construir apunts. gdt e idt en GDT donde el BIOS los espera. */ 

07828 dtp= (struct desctableptr_s *) &gdt[GDT_INDEX]; 

07829 * (ul6 t *) dtp->limit = (sizeof gdt) -1; 

07830 * (u32 t *) dtp->base = vir2phys(gdt)j 

07831 

07832 dtp= (struct desctableptr s *) &gdt[IDT INDEX]; 

07833 * (ul6 t *) dtp->limit = (sizeof idt) -1; 

07834 * (u32_t *) dtp->base = vir2phys(idt); 

07835 

07836 /* Construir descriptores de segm. para tareas y manejo de interrupciones. */ 

07837 init_codeseg(&gdt[CS JNDEX], codejase, codeJytes, INTR PRIVILEGE); 

07838 init_dataseg(&gdt[DS INDEX], datá base, data bytes, INTR PRIVILEGE); 

07839 init_dataseg(&gdt[ES JNDEX], 0L, 0L, TASK PRIVILEGE); 

07840 

07841 /* Construir descriptores desechables para funciones en klib88. */ 

07842 init_dataseg(&gdt[DS_286JNDEX], (physjytes) 0, 

07843 (physbytes) MAX 286_SEG_SIZE, TASK PRIVILEGE); 

07844 init_dataseg(&gdt[ES_286 INDEX] , (physjytes) 0, 

07845 (phys bytes) MAX 286 SLG_SIZE, TASK PRIVILEGE); 

07846 

07847 /* Construir descriptores locales en GDT para LDT en tabla de proc. 

07848 * Los LDT se asignan durante la compilación en la tabla de procesos 

07849 * Y se inicializan cuando se inicial iza o modifica el mapa de un proceso. 

07850 */ 

07851 for (rp = BEG PROC ADDR, Idt selector = FIRST LDT JNDEX * DESC_SIZE; 

07852 rp < END PROC ADDR; ++rp, Idt selector += DESC_SIZE) { 

07853 init_dataseg("gdt[ldt_selector / DESCSIZE], vir2phys(rp->pjdt), 

07854 (phys bytes) sizeof rp->p Idt, INTR PRIVILEGE); 

07855 gdtjldt selector / DESC_SIZE] .access ~ PRESENTI LDT; 

07856 rp->pjdt_sel = ldt_selector; 

07857 } 

07858 

07859 /* Construir TSS principal. 

07860 * Esto se usa sólo para registrar el apuntador a pila que se usará 

07861 * después de una interrupción. 

07862 * El apuntador se prepara de modo que una interrupción guarde 

07863 * automáticamente los registros del proceso actual ip:cs:f:sp:ss 

07864 * en la tabla de procesos. 

07865 */ 

07866 tss.ssO = DS SELECTOR; 

07867 init_dataseg(&gdt[TSS INDEX], vir2phys(&tss), (phys bytes) sizeof tss, 

07868 INTR PRIVILEGE); 

07869 gdt[TSS JNDEX] .access = PRESENT I (INTR PRIVILEGE « DPL SHIFT) I TSS_TVPEj 

07870 tss.iobase = sizeof tss; /* mapa de permisos de e/s vacío */ 

07871 

07872 /* Construir descriptores para puertas de interrupción en IDT. */ 

07873 for (gtp = &gate table[0] j 

07874 gtp < &gate_table[sizeof gate table / sizeof gate_table[0]]; ++gtp) { 
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07875 int_gate(gtp->vec_nr, (physbytes) (vir_bytes) gtp->gate, 

07876 PRESENT IINT GATE TYPE I (gtp->privilege « DPL SHIFT)); 

07877 } 

07878 int gate (SYSJVECTOR , (phys_bytes) (yjrbytes) p_s_call, 

07879 PRESENT I (USER PRIVILEGE « DPL SHIFT) I INT GATEJTYPE); 

07880 int_gate (LEVELO VECTOR , (phys_bytes) (vir_bytes) level0_call, 

07881 .PRESENT I (TASK PRIVILEGE « DPL SHIFT) I INT GATEJTYPE); 

07882 int_gate(SYS386 VECTOR, (phys_bytes) (vir_bytes) s_call, 

07883 PRESENT I (USER PRIVILEGE « DPL SHIFT) I INT GATEJTYPE); 

07884 } 

078IS§#W . . ^ srsc- r-.y/vVQ . .r-'-u.-jS.-'V 
07887 * init_codeseg 

07888 *=========================*/ 

07889 PUBLIC vaid init_codeseg(segdp, base, size, privilege) 

07890 register struct segdescs *segdp; 

07891 phys bytes base; 

07892 physbytes size; 

07893 int privilege; 

07894 { 

07895 /* Construir descriptor de un segmento de código, */ 

07896 

07897 sdesc(segdp, base, size); 

07898 segdp->access = (privilege « DPL SHIFT) 

07899 I (PRESENT I SEGMENT IEXECUTABLE IREADABLE); 

07900 /* CONFORMING = 0, ACCESSED = 0 */ 

07901 } 

07903 /*======================================================* 

07904 * initdataseg 

07905 *=====================================================*/ 

07906 PUBLIC void init dataseg(segdp, base, size, privilege) 

07907 register struct segdesc s *segdp; 

07908 phys bytes base; 

07909 phys bytes size; 

07910 int privilege; 

07911 { 

07912 /* Construir descriptor de un segmento de datos. */ 

07913 

07914 sdesc(segdp, base, size); 

07915 segdp->access = (privilege « DPL SHIFT) I (PRESENT I SEGMENT IWRITEABLE); 

07916 /* EXECUTABLE = 0, EXPAND DOWN = 0, ACCESSED = 0*1 

07917 } 

079g||fe" ^ ■■■ ■ ■ 

07920 * sdesc 

07921 *===== - ==== ^- ====== - ========*/ 

07922 PRIVATE vaid sdesc(segdp, base, size) 

07923 register struct segdesc s *segdp; 

07924 phys_bytes base; 

07925 phys bytes size; 

07926 { 

07927 /* Llenar campos de tamaño (base, límite y granularidad) de un descriptor. *1 

07928 

07929 segdp->base low = base; 

07930 segdp->base middle = base » BASE MIDDLE SHIFT; 

07931 segdp->base high = base » BASE HIGH SHIFT; 

07932 —size; /* convertir a límite, tamo 0 implica 4G */ 

07933 if (size > BYTE GRAN_MAX) { 

07934 segdp->limit low = size » PAGE GRAN SHIFT; 
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07935 segdp->granularity = GRANULAR 1 (size » 

07936 (PAGE GRAN SHIFT + GRANULARITY SHIFT)); 

07937 } else { 


07939 
07940 
07941 
07942 
07944 /• 
07945 " 
07946 * 


egdp->granularity = size » GRANULARITY SHIFTj 

,segdp->granularity 1= DEFAULTj /* Significa BIG p/seg. datos */ 

} 

seg2phys 


07947 PUBLIC physbytes seg2phys(seg) 


07949 { 

07950 /* Devolver la dirección base de un segmento; seg es un registro 
07951 * de segmento 8086 o bien un se lector de segmento 286/386. 
07952 */ 

07953 physbytes basej 
07954 struct segdesc s *segdpj 


07956 if (Iprotected mode) { 

07957 base = hclick_to_physb(seg); 

07958 } else { 

07959 segdp = &gdt[seg » 3] j 

07960 base = segdp->base_low 1 ((u32_t) segdp->base_middle« 16); 

07961 base 1= ((u32j) segdp->base_high« 24)j 

07962 } 

07963 retum base; 


07967 * intrate 

07968 *= - ============ - */ 

07969 PRIVATE void int_gate(vec_nr, base, dpl type) 

07970 unsigned vec_nr; 

07971 phys bytes base; 

07972 unsigned dpl_type; 

07973 { 

07974 /* Construir descriptor para puerta de interrupción. */ 

07975 

07976 register struct gatedesc s *idp; 

07977 

07978 idp = &idt[vec_nr]; 

07979 idp->offset low = base; 

07980 idp->selector = CS_SELECTOR; 

07981 idp->p dpl_type = dpi type; 

07982 idp->offset high = base » OFFSET H1GH SHIFT; 

07983 } 

079^r=^ ^"'- :j ^ ' • ™ 'ig'KY'v.iJ' i ■■ ■£ -■■? ■ - tPF JT. >. < ■ 

07986 * enable iop 

079 ^^é¡t-^jeygj7i% i ir?fflrá =================================================*/ 

07&88 PUBLIC void enableJop(pp) 

07989 struct proc *pp; 

07990 { 

07991 /* Permitir a un proc. usuario usar instruc. de E/S. Cambiar los bits de permiso 

07992 * de E/S en psw. Estos especifican el nivel de permiso actual (CPL) 

07993 * menos privilegiado que puede ejecutar instruc. de E/S. Usuarios y servidores 
07994 * tienen CPL 3, que es el más bajo. Kemel tiene CPL 0, tareas CPL 1. 
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07995 */ 

07996 pp->p_reg.psw 1= 0x3000; 

07997 } 


src/kemel/klib.s 


08000 # 

08001 /*! Escoge entre versiones 8086 y 386 de cód. de kemel de bajo nivel.*/ 

08002 

08003 #include <minix/config.h> 

08004 #if WDRD SIZE = 2 

08005 #include "klib88.s" 

08006 #else 

08007 #include "klib386.s" 

08008 #endif 


src/kemel/klib386.s 

08100 

08101 /* sections*/ 

08102 

08103 .sect .text; .sect .rom; .sect .data; .sect .bss 

08104 

08105 #include <minix/config.h> 

08106 #include <minix/const.h> 

08107 #include "const.h" 

08108 #include "sconst.h" 

08109 #include "protect.h" 

08110 

08111 /* Este archivo contiene varias rutinas de utilería en código ensamblador*/ 

08112 /* requeridas por el kemel. Son:*/ 

08113 

08114 #defme _monitor! salir de Minix y volver al monitor 

08115 #define _check_mem /* revisar bloque memoria, devolver tamaño válido */ 

08116 #defme _cp_mess /* copia mensajes de origen a destino */ 

08117 #defme _exit /* ficticia para rutinas de biblioteca */ 

08118 #define —exit /* ficticia para rutinas de biblioteca */ 

08119 #define —exit /* ficticia para rutinas de biblioteca */ 

08120 #define —main /* ficticia para GCC */ 

08121 #define _in_byte /* leer byte de un puerto y devolverlo */ 

08122 #define in_word /* leer palabra de un puerto y devolverla */ 

08123 #define _out_byte /* escribir un byte en un puerto */ 

08124 #define _out_word /* escribir una palabra en un puerto */ 

08125 #define _port_read /* transí, datos de puerto (cont. disco) a memoria */ 

08126 #define _port_read_byte /* lo mismo byte por byte */ 

08127 #define _port_write /* transí, datos de memoria a puerto (cont. disco) */ 

08128 #define _port_write_byte /* lo mismo byte por byte */ 

08129 #define_lock /* inhabilitar interrupciones */ 

08130 #define _unlock /* habilitar interrupciones */ 

08131 #define _enable_irq /* habilitar irq en controlador 8259 */ 

08132 #define _disable_irq /* inhabilitar un irq */ 

08133 #define _phys_copy /* copiar datos dentro de la memoria*/ 

08134 3define _mem_rdw /* copiar palabra de [segmento:distancia;] */ 
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08135 

08136 

08137 

08138 

08139 

08140 

08141 

08142 

08143 

08144 

08145 

08146 

08147 

08148 

08149 

08150 

08151 

08152 

08153 

08154 

08155 

08156 

08157 

08158 

08159 

08160/* 

08161* 


#defíne _reset 
#defme _mem_vid_copy 
#define _vid_vid_copy 
#defme leve 10 


/* restablecer sistema */ 

/* copiar datos en ram de video */ 
/* mover datos en ram de video */ 
/* invocar función en nivel 0 */ 


/* Las rutinas sólo garantizan preservar los registros que el compilador 
* , de C espera se preserven (ebx, esi, edi, ebp, esp, registros de segmento 
/* Y bit de dirección en las banderas). 

/* variables importadas*/ 


.extern _mon_retum, _mon_sp 
.extern _irq_use 
.extern _blank_color 
.extern _ext_memsize 
.extern _gdt 
.extern _low_memsize 
.extern _sizes 
.extern _vid_seg 
.extern _vid_size 
.extern _vid_mask 
.extern level0_func 


08162 

08163 

08164 

08165 

08166 

08167 

08168 

08169 

08170 

08171 

08172 

08173 

08174 

08175 

08176 

08177 

08178 

08179 


PUBLIC void monitor(); 
Regresar al monitor. 


monitor: 


eax, (_reboot_code) 
esp, (_mon_sp) 
dx, SSSELECTOR 


/* dir. de nuevos parámetros */ 

/* restaurar apunto a pila del monitor */ 
/* segmento de datos del monitor */ 


/* regresar al monitor*/ 


08182* checkmem 

08183 /♦ = === = == = === = =============== == ===== = = 

08184 PUBLIC phys_bytes check_mem(phys_bytes base, phys_bytes size); 

08185 /* Revisar bloque de memoria, devolver la cantidad válida. 

08186 * Sólo se revisa cada 160. bloque. 

08187 * Un tamaño inicial de 0 significa todo. 

08188 /* Esto realmente debería verificar algunos alias. 

08189 

08190 CM DENSITY = 16 

08191 CM LOG DENSITY = 4 

08192 TEST 1PATTERN 
08193 TEST2PATTERN 
08194 


0x55 /* patrón de prúeba de memoria 1; 
OxAA/* patrón de prueba de memoria 2; 
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08195 

CHKMARGS 

4 + 4 + 4 

/* 4 + 4 */ 

08196 

08197 

08198 

checkmem: 

ds ebx eip 

/* tamaño base */ 

08199 

push 

ebx 


08200 

push 

ds 


08201 

016 mov 

ax, FLAT DS SELECTOR 


08202 

mov 

ds, ax 


08203 

mov 

eax, CHKM ARGS(esp) 


08204 

mov 



08205 

mov 

ecx, CHKM ARGS+4(esp) 


08206 

08207 

cm loop: Shr 

ecx, CM LOG DENSITY 


08208 


di, TEST 1PATTERN 


08209 

xchgb 

di, (eax) 

/* escribo pat. prueba, recordar original*/ 

08210 

xchgb 

di, (eax) 

/* restaurar original, leer pat. Prueba */ 

08211 

empb 

di, TEST 1 PATTERN 

/* coincide si memoria real buena */ 

08212 

jnz 


/* si diferente, memoria inutilizable */ 

08213 

movb 

di, TEST2PATTERN 


08214 

xchgb 

di, (eax) 


08215 

xchgb 

di, (eax) 


08216 

add 

eax, CM DENSITY 


08217 

empb 

di, TEST2PATTERN 


08218 

08219 

cmexit: ^ 

cm-looP 


08220 

sub 

eax, ebx 


08221 

por 

ds 


08222 

08223 

re P t° r 

ebx 



PUBLIC void cp_mess(int src, phys_clicks src_clicks,vir_bytes src_offset, 
/*phys_clicks dst_clicks, vir_bytes dst_offset); 

* Copia rápida de un mensaje de cualquier lugar del espacio de dir. 

* a cualquier otro. También copia la dirección de origen que es parámetro 

* de la llamada en la la. palabra del registro de destino. 

* El tamaño de mensaje "Msize" está en DWORDS (no bytes) y debe 

* ajustarse correctamente. Cambiar la definición de un mensaje en el archivo 

* de tipo y no cambiarlo aquí conduce a un desastre total. 


08224 

08225 

08226 /« 

08227 

08228 * 

08229 

08230 

08231 

08232 

08233 

08234 

08235 

08236 

08237 

08238 

08239 

08240 

08241 

08242 

08243 _ 

08244 

08245push 

08246push 

08247push 

08248push 

08249 

08250 

08251 

08252 

08253 

08254 


proc sel sof del dof*/ 


ax, FLATDSSELECTOR 


■si, CM_ARGS+4(esp) 
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08255 

08256 

08257 

08258 

08259 

08260 

08261 

08262 

08263 

08264 

08265 

08266 

08267 

08268 

08269 

08270 

08271 

08272 

08273 

08274 

08275 I" 

08276* 

08277 * 

08278 

08279 

08280 

08281 

08282 

08283 _ 

08284 

08285 

08286 

08287 

08288 

08289 _ 

08290 

08291 

08292 

08293*= 

08294* 

08295 * 

08296 

08297 

08298 

08299 

08300 _ 

08301 

08302 

08303 

08304 

08305 

08306 

08307 * 

08308* 

08309 * 

08310 

08311 

08313 

08314 


shl esi, CLICKSHIFT 

add esi, CM_ARGS+4+4(esp) 

mov edi, CM_ARGS+4+4+4(esp) 

shl edi, CLICK SHIFT 

add edi, CM_ARGS+4+4+4+4(esp) 


/* distancia origen*/ 
/* clics destino*/ 

/* distancia destino*/ 


eax, CM ARGS(esp) 


add esi, 4 

mov ecx, Msize-1 

rep 


/* núm. proc. de emisor*/ 

/* copiar # emisor en mensaje dest.*/ 
/* no copiar primera palabra */ 

/* la primera palabra no cuenta */ 

/* copiar el mensaje*/ 


pop 

pop 

pop 

pop 


/* eso es todo amigos*/ 


PUBLIC void exit(); 

/* Algunas rutinas de bibl. usan exit, así que necesitamos versión ficticia. 

* No puede haber llamadas reales a exit en el kemel. 

* GNU CC gusta de llamar —main desde main() por razones no obvias. 


jmp _exit 


in_byte 


PUBLIC unsigned in_byte(port_t portjj 
Leer byte (sin signo) de puerto de E/S port y devolverlo. 

.align 16 

in_byte: 

mov edx, 4(esp) ! puerto 

inb dx 1 leer 1 byte 




PUBLIC unsigned in_word(port_t port); 

I Leer palabra (sin signo) de puerto de E/S port y devolverla. 08312 
.align 16 
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08315 mov edx, 4(esp) 

08316 sub eax,eax 

08317 016 in dx 

08318 ret 


! puerto 

1 leer una palabra 


08319 

08320 

08321 * 

08322* 

08323 * 

08324 

08325 

08326 

08327 

08328 _ 

08329 

08330 

08331 

08332 

08333 

08334 

08335 /*■ 

08336* 

08337 /*■ 

08338 

08339 

08340 

08341 

08342 _ 

08343 

08344 

08345 

08346 

08347 

08348 

08349 * : 

08350* 

08351 * 

08352 

08353 

08354 

08355 

08356 

08357 

08358 

08359 

08360 

08361 

08362 

08363 

08364 

08365 

08366 

08367 

08368 

08369 

08370 

08371 

08372 

08373 

08374 


out_byte 


PUBLIC void out_byte(port_t port, u8_t valué); 

/* Escribir valor (mutado a byte) en el puerto de E/S port.*/ 

.align 16 

out_byte: 

mov edx, 4(esp) /* puerto*/ 

movb al, 4+4(esp) /* valor */ 

outb dx /* 1 byte a la salida */ 




PUBLIC void out_word(Port_t port, U16_t valué); 

/* Escribir valor (mutado a palabra) en el puerto de E/S port.*/ 


outword: 

16 


mov 

edx, 4(esp) 

/* puerto*/ 

mov 

eax, 4+4(esp) 

/* valor*/ 

016 outdx 

/* 1 palabra a la salida*/ 



port_read 


PUBLIC void port_read(port_t port, phys_bytes destination, unsigned bytcount); 
/* Transferir datos de puerto (controlador disco duro) a memoria.* 


PRARGS = 


_port_read: 

cid 


rep 

016 


pop 

pop 


16 


edi 

ecx, FLATDSSELECTOR 

edx, PR ARGS(esp) 
edi, PR_ARGS+4(esp) 
ecx, PR_ARGS+4+4(esp) 
ecx, 1 


edi 


4 + 4 + 4 /* 4 + 4 + 4*/ 

/*es edi eip port dst len*/ 


/* puerto del cual leer*/ 

/* dir. de destino*/ 

/* cuenta de bytes*/ 

/* cuenta de palabras*/ 

/* (hardware no maneja palo dobles) */ 
/* leer todo */ 
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08375 
08376 * 

08377 * portreadbyte 


08379 

08380 

08381 

08382 

08383 

08384 

08385 

08386 

08387 


08391 

08392 

08393 

08394 

08395 


PUBLIC void port read byte(port t port, phys bytes destination, 
.unsigned bytcount); 

/* Transferir datos de puerto a memoria.*/ 

PR ARGS B =4 + 4 + 4 /* 4 + 4 + 4*/ 

/*es edi eip port dst len */ 


port read byte: 
cid 




rep 




ecx, FLATDS SELECTOR 

edx, PR ARGS B(esp) 
edi, PR ARGS B+4(esp) 
ecx, PR ARGS B+4+4(esp) 


08397 pop es 

08398 pop edi 


08402 


08403 * port_write 

08404 *===== - == - ======= - = = 

08405 PUBLIC void port write(port t port, physbytes source, unsigned bytcount); 

08406 /* Transferir datos de memoria a puerto (controlador disco duro).*/ 

08407 

08408 PWARGS = 4 + 4 + 4 /*4 + 4 + 4*/ 

08409 /* es edi eip port src len */ 

08410 


08411 

08412 

08413 

08415 

08416 

08417 

08418 

08419 

08420 

08421 

08422 

08423 

08424 

08425 

08426 

08427 


cid 08414 




16 


ds 

ecx, FLAT DS SELECTOR 
ds, ex 

edx, PW_ARGS(esp) 
esi, PW ARGS+4(esp) 
ecx, PW ARGS+4+4(esp) 



/* puerto al cual escribir*/ 


/* cuenta de bytes*/ 

/* cuenta de palabras*/ 

/* (hardware no maneja palo dobles)*/ 
/* escribir todo*/ 


08430 * port_write_byte 

08431 * 

08432 PUBLIC void port write byte(port_t port, phys bytes source, 
08433 unsigned bytcount); 

08434 /* Transferir datos de memoria a puerto.*/ 
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08435 

08436 PW ARGS B = 4 + 4 + 4 /* 4 + 4 + 4*/ 

08437 /* es edi eip port src len */ 

08438 

08439 _port_write_byte: 

08440 cid 

08441 .push esi 

08442 push ds 

08443 mov ecx, FLATDSSELECTOR 

08444 mov ds ex 

08445 mov edx, PW_ARGS_B(esp) 

08446 mov esi, PW_ARGS_B+4(esp) 

08447 mov ecx, PW_ARGS_B+4+4(esp) 

08448 rep 

08449 outsb 

08450 pop ds 

08451 pop esi 

08452 ret 

08453 
08454 

08455 /<■ = === = == = == == == = = == === == ===== = == 

08456* lock 

08457 *==—== === == = === == = = = = = === 

08458 PUBLIC void lock(); 

08459 /* Inhabilitar interrupciones de CPU.*/ 

08460 

08461 .align 16 

08462 _ lock: 

08463 cli /* inhabilitar interrupciones*/ 

08464 ret 

08465 

08466 

08467 *============================== = ======== = ===: 

08468* unlock 

08469 *========= = ==================== = ======== = ===: 

08470 PUBLIC void unlock(); 

08471 /* Habilitar interrupciones de CPU.*/ 

08472 

08473 .align 16 

08474 unlock: 

08475 sti 

08476 ret 

08477 
08478 

08479 *====== === = == == == === = = = = == = = = === == 

08480* enable_irq 

08481 *== = == == = = == = ===================== == = = = = = == = 

08482 PUBLIC void enable_irq(unsigned irq); 

08483 /* Habilitar linea de solic. de interrupción apagando un bit de 8259. 

08484 * Código equivalente para irq < 8: 

08485 out_byte(INT_CTLMASK, in byte(INT CTLMASK) & -(1 «irq)); 

08486 

08487 .align 16 

08488 _enable_irq: 

08489 mov ecx, 4(esp) /* irq*/ 

08490 pushf 

08491 cli 

08492 movb ah,-l 

08493 rolb ah, el /* ah = -(1 « (irq % 8» 

08494 empb el, 8 
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08495 

jae enable 8 

! hábil, irq >= 8 en 8259 esclavo 

08496 

enable 0: 


08497 

inb INT CTLMASK 


08498 

andb al, ah 


08499 

outb INT CTLMASK 

! apagar bit en 8259 maestro 

08500 

popí 


08501 



08502 

.align 4 


08503 

enable 8: 


08504 

inb INT2 CTLMASK 


08505 

andb al, ah 


08506 

outb INT2 CTLMASK 

! apagar bit en 8259 esclavo 

08507 

popí 


08508 



08509 



08510 






08512 

* disable_irq 

* 




08514 

PUBLIC int disable irq(unsigned irq) 


08515 

/* Habilitar línea de solicitud de int. actr 

vando un bit del 8259. 

08516 

* Código equivalente para irq < 8: 


08517 

out byte (INT CTLMASK, in byte(IN 

T CTLMASK) I (1 « irq)); 

08518 

/* Devuelve trae si la interrupción no est 

aba ya inhabilitada.*/ 

08519 



08520 

.align 16 


08521 

disable irq: 


08522 

mov ecx, 4(esp) 

/* irq*/ 

08523 



08524 

P cli 


08525 

movb ah, 1 


08526 

rolb ah, el 

/* ah = (1 « (irq % 8))*/ 

08527 

empb el, 8 


08528 

jae disable_8 

/* inhábil, irq >= 8 en 8259 esclavo 

08529 

disable 0: 


08530 

inb INTCTLMASK 


08531 

testb al, ah 


08532 

jnz dis_already 

/* ¿ya inhabilitada?*/ 

08533 

orb al, ah 


08534 

outb INT CTLMASK 

/* activar bit en 8259 maestro*/ 

08535 

popí 


08536 

mov eax, 1 

/* inhábil, por esta función*/ 

08537 

ret 


08538 

disable 8: 


08539 

inb INT2CTLMASK 


08540 

testb al, ah 


08541 

jnz dis_already 

/* ¿ya inhabilitada?*/ 

08542 

orb al, ah 


08543 

outb INT2CTLMASK 

/* activar bit en 8259 esclavo*/ 

08544 

popí 


08545 

mov eax, 1 

/* inhábil, por esta función*/ 

08546 

ret 


08547 

disalready: 


08548 

popf 


08549 


/* ya in habilitada*/ 

08550 

ret 


08551 



08552 



08554* 

phys_copy * 
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08555 * 
08556 
08557 
08558 
08559 
08560 
08561 
08562 
08563 
08564 
08565 
08566 
08567 
08568 
08569 
08570 
08571 
08572 
08573 
08574 
08575 
08576 
08577 
08578 
08579 


/* PU8LIC void phys coPy(phys_bytes source, physbytes destination, 
/*PhysJrytes bytecount);*/ 

/* Copiar un bloque de memoria física.*/ 

PCARGS = 4 + 4 + 4 + 4 /* 4 + 4 + 4*/ 

.es edi esi eip src dst len */ 

.align 16 

phys copy: 
cid 

push edi 


K, FLAT DS SELECTOR 


mov esi, PC ARGS(esp) 

mov edi, PC_ARGS+4(esp) 

mov eax, PC_ARGS+4+4(esp) 

cmp eax, 10 /* evitar gasto alineac. p/cuentas peq.*/ 

jb pcsmall 

mov ecx, esi /* alinear origen, ojalá objetivo tambo*/ 


08580 neg 

08581 and 

08582 sub 

08583 rep 

08584 eseg movsb 
08585 mov 

08586 shr 

08587 rep 

08588 eseg movs 
08589 and 

08590 pcsmall: 


/* cuenta p/alineación */ 


/* cuenta de palabras dobles*/ 


08591 xchg ec: 

08592 rep 

08593 eseg movsb 
08594 

08595 pop es 

08596 pop edi 

08597 pop esi 

08598 ret 


/* residuo*/ 


08599 

08600 


08602 * memrdw 

086( ^L»^:^ 'jrí 

08604 /* PUBLIC ul6_t mem_rdw(U16j segment, ul6_t *offset);*/ 

08605 /* Cargar y devolver palabra en apunto lejano segmento:distancia.*/ 

08606 

08607 .align 16 

08608 memrdw: 

08609 mov ex, ds 

08610 mov ds, 4(esp) 

08611 mov eax, 4+4(esp) 

08612 movzx eax, (eax) 

08613 mov ds, ex 

08614 ret 


/* segmento*/ 

/* distancia */ 

/* palabra por devolver*/ 
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08620 
08621' 
08622 
08623 
08624 
08625 
08626 
08627 
08628 
08629 
08630 
08631/ 
08632 
08633 ■ 
08634 
08635 
08636 
08637 
08638 
08639 


>n distancia 0 e interrumpiendo.*/ 


! todo vale; al 386 no le gustará 


PUBLIC void mem vid_copy(ul6 *src, unsigned dst, unsigned count); 

* Copiar count caracteres de memoria kemel a memoria video. Src, dst 

* Y count son distancias y cuentas de video basadas en caracteres (pal.). 

* Si src es nuil se borra la memo pantalla llenándola con blank color. * 


08645 

08646 

08647 

08648 

08649 

08650 

08651 

08652 

08653 

08654 

08655 

08656 

08657 

08658 

08659 

086600: 

08661 

08662 

08663 

08664 

08665 

08666 

08667 


:m_vid copy: 


esi, MVC ARGS(esp) 
edi, MVC ARGS+4(esp) 
edx, MVC_ARGS+4+4(esp) 
es, (_vid seg) 


edi, (_vid mask) 
eax, (_vid_size) 


/* origen*/ 

/* destino */ 

/* destino es segm. Video */ 

/* asegurar direc. hacia arriba */ 


/* copiar palabras er 


08670 

08671 

08672 

08673 

08674 


/* direcciones de palabras * 
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08675 test edx, edx 

08676 jnz mvc loop 

08677 mvc done: 

08678 pop es 

08679 pop edi 

08680 pop esi 

08681 .ret 

08682 


08687 PUBLIC void vid_vid_copy(unsigned src, unsigned dst, unsigned count); 

08689 /* Copiar count caracteres de memo video a memo video. Manejar traslapo. 

08690 * Sirve para despl. pantalla, insertar o elim. líneas o caro Src, dst y count 

08691 * son distancias y cuentas de video basadas en caracteres (pal.)*/ 


08693 WCARGS = 4 + 4 + 4 + 4 /* 4 + 4 + 4*/ 

08694 -es edi esi eip src dst ct 


08696 

08697 


08700 

08701 

08702 

08703 

08704 

08705 

08706 

08707 


08710 

08711 

08712 

08713 

08714 

08715 

08716 

08717 

08718 

08719 

08720 

08721 

08722 

08723 

08724 

08725 

08726 

08727 

08728 

08729 

08730 

08731 

08732 

08733 

08734 


vid vid_copy: 

push edi 



esi, WC_ARGS(esp) 
edi, VVC ARGS+4(esp) 
edx, W C_ARGS+4+4(esp) 
es, (_vid_seg) 


-cid 

wc uploop: 

-andesi, (_vid_mask) 
and edi, (_vid_mask) 

mov ecx, edx 

mov eax, (_vid size) 




jbe Of 




shl 

shl 


mov eax, (_vid_size) 


Of 

edx, ecx 
esi, 1 
edi, 1 


shr esi, 1 

shr edi, 1 

test edx, edx 

jnz wc uploop 

jmp wcdone 


lea esi, -1 (esi) (edx*l) 


/* origen*/ 

/* destino */ 

/* cuenta */ 

/* usar segmento de video */ 

/* ¿copiar hacia arriba o abajo?*/ 

/* dirección es hacia arriba*/ 

/* continuar dir. al principio */ 

/* un trozo por copiar */ 


/* ecx = min(ecx, vid_size 




/* ecx = min(ecx, vidsize -edi)*/ 

/* direcciones de bytes */ 

/* copiar palabras de video */ 

/* direcciones de palabras */ 

/* ¿otra vez?*/ 


/* dirección es hacia abajo */ 
/* comenzar a copiar arriba */ 
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08735 

08736 

08737 

08738 

08739 

08740 

08741 

08742 

08743 

08744 0: 

08745 

08746 

08747 

08748 0: 

08749 

08750 

08751 

08752 

08753 

08754 

08755 

08756 

08757 

08758 

08759 

08760 

08761 

08762 

08763 

08764 

08765 

08766 /** 

08767 * 

08768 *== 

08769 

08770 

08771 

08772 

08773 

08774 

08775 

08776 

08777 


lea edi,-1 (edi)(edx*l) 

wc downloop: 

-and esi, (_vid_mask) 

and edi, (_vid_mask) 

lea eax, 1 (esi) 

jbe Of 

lea eax, 1 (edi) 

jbe Of 


sub edx, ecx 

shl esi, 1 

shl edi, 1 


eseg 016 movs 
shr esi, 1 

shr edi, 1 

jnz wc downloop 

cid 

Ijmp vvcdone 


pop es 

pop edi 

pop esi 


/* continuar dir. al principio */ 
/* un trozo por copiar */ 

/* ecx = min(ecx, esi + 1) */ 

/* ecx = min(ecx, edi + 1) */ 

/* direcciones de bytes */ 

/* copiar palabras de video *1 
/* direcciones de palabras */ 

/* ¿otra vez? */ 

/* compilador C espera arriba */ 


levelO 


PU8LIC void level0(void (*func)(void» 

/* Llamar función en nivel de permiso 0. Permite a tareas de kemel 
hacer cosas sólo posibles en el nivel más privilegiado de CPU. 

levelO: 

mov eax, 4(esp) 

mov (_leveI0 fuñe), eax 

int LEVELOVECTOR 


src/kemel/misc.c 


08800 /* Este archivo contiene una colección de procedimientos diversos: 
08801 * meminit: inic. tablas de memo Algo de memo i 

08802 * -algo se estima y verifica después 

08803 * env_parse analizar variable de entorno. 

08804 * bad assertion para depuración 

08805 * bad=compare para depuración 


08806 */ 
08807 


informada por 8IOS, 


08808 #include "kemel.h" 
08809 #include "assert.h" 










EL CÓDIGO FUENTE DE MINIX 


Archivo: src/kemel/misc.c 


633 


08810 #include <stdlib.h> 

08811 #include <minix/com.h> 

08812 

08813 #deñne EM_BASE OxlOOOOOL 

08814 #defme SHADOWBASE OxFAOOOOL 
08815 #define SHADOW MAX 0x060000L 


/* base de memo extendida en AT */ 

/* base de RAM sombra de ROM en algo AT */ 
/* memo sombra utilizable máx. (lím. 16M) */ 


08820 PUBLIC void mem_init0 
08821 { 

08822 !* Inic. tablas de tamaño de memoria. Esto se complica por fragmentación 
08823 * Y diferentes estrato de acceso p/modo protegido. Debe haber un trozo en 0 

08824 * suficiente para contener Minix prop. dicho. Para 286 y 386 puede haber memo 

08825 * extendida (más de 1MB) que suele comenzar en 1MB, pero puede 

08826 * haber otro trozo justo abajo de 16MB, reservada bajo DOS p/sombra 

08827 * de ROM, pero disponible p/Minix si se puede re-mapear el hardware. 

08828 * En modo protegido, la memo ext. está disponible si CLICK_SIZE 

08829 * es lo bastante grande, pero se trata como memo ordinaria. 

08830 */ 

08831 

08832 u32_t ext_clicks; 

08833 phys clicks max_clicks; 

08834 

08835 /* Obtener tamaño de memoria ordinaria del BIOS. */ 

08836 mem[0] .size = k_to_click(low_memsize); /* base = 0 */ 

08837 

08838 if (pc_at && protected mode) { 

08839 /* Obtener el tamaño de memo ext. del BIOS. Esto es especial excepto 

08840 * en modo protegido, pero el modo prot. ahora es normal. No se puede 

08841 * direccionar más de 16M en modo 286, así que hay que asegurarse 

08842 * de que la dir. de memoria más alta quepa holgadamente si se cuenta 

08843 * en clics. 


08845 ext clicks = k to_click((u32_t) ext memsize); 

08846 max clicks = USHRT MAX -(EM BASE » CLICK SHIFT); 

08847 mem[l] .size = MIN(ext_clicks, max_clicks); 

08848 mem[l] .base = EM BASE» CLICK SHIFT; 

08849 

08850 if (ext_memsize <= (unsigned) ((SHADOW BASE -EM_BASE) / 1024) 

08851 && check mem (SHADOW BASE , SHADOW MAX) == SHADOW MAX) { 

08852 /* Memoria sombra de ROM. */ 

08853 mem[2] .size = SHADOW_MAX» CLICK SHIFT; 

08854 mem[2] .base = SHADOW BASE» CLICK SHIFT; 

08855 } 


08857 

08858 /* Memoria total del sistema. */ 

08859 totmemsize = mem[0] .size + mem[l] .size + mem[2] .size; 
08860 } 

088Ü^—============== 


08865 PUBLIC int env_parse(env, fmt, field, 
08866 char *env; 

08867 char *fmt; 

08868 int field; 

08869 long *param; 


variable de entorno que inspeccionar */ 
/* plantilla para analizarla */ 

/* núm. campo del valor por devolver *1 
/* dir. del parámetro por obtener */ 
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08870 long min, max; i* valores mino y máx. para el parámetro */ 

08871 { 

08872 /* Analizar variable de entorno, algo como "DPETFI0=300:3". Pánico 

08873 * si falla el análisis. Devolver EP UNSET si la variable no está establecida, 
08874 * EP OFF si está en "off’, EP ON si-está en "on" o un campo está en 
08875 * blanco, o EPSET si se da un campo (devolver valor con *param). 

08876 * Pued~n usarse comas y dos puntos en la cadena de entorno y formato, 
08877 * puede haber campos vacíos en la cadena de entorno, y puede faltar 
08878 * puntuación para saltarse campos. La cadena de formato contiene 
08879 * caracteres 'd', 'o', ’x' y 'c' p/indicar que se usa 10, 8, 16 o 0 
08880 * como último arg. de strtol. 

08881 */ 


08883 char *val, *end; 

08884 long newpar; 

08885 int i = 0, radix, r; 

08886 

08887 if ((val = k getenv(env)) = NIL PTR) retum(EP_UNSET); 

08888 if (strcmp(val, "off') == 0) retum(EPJ3FF); 

08889 if (strcmp(val, "on”) = 0) retum(EP ON); 

08890 

08891 r = EPON; 

08892 for (;;) { 

08893 while (*val =' ’) val++; 


08902 

08903 

08904 

08905 

08906 

08907 


08912 

08913 

08914 

08915 


if (*val =»=i||retum(r); 
if (*fmt == 0) break; 


I* punto de salida correcto */ 
/* demasiados valores */ 


if (*val = ','11 *val ==':') { 

/* Momento de pasar a siguiente campo. */ 
if (*fmt = ','11 *fmt = ':') i++; 
if (*fmt++ = *val) val++; 

} else { 

/* Entorno contiene un valor, obtenerlo. */ 
switch (*fmt) { 

case ’d': radix = 10; break; 

case 'o': radix = 010; break; 

case'x': radix = 0x10; break; 

case 'c': radix = 0; break; 

default: goto badenv; 


newpar = strtol(val, &end, radix); 


if (end = val) break; /* no es un número. */ 

val = end; 


08917 

08918 

08919 

08920 

08921 

08922 

08923 

08924 

08925 

08926 

08927 

08928 

08929 


if0^ field) { 

/* El campo solicitado. */ 
if (newpar < min 11 newpar > max) break; 
*param = newpar; 
r = EPSET; 

} 

} 


badenv: 

printf("8ad environment setting: '%s = %s'\n", env, k_getenv(env)); 
panic("", NO_NUM); 

/*NOTREACHED*/ 

} 
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08931 #if DEBUG 

08932 /«=——=== . = . == . .= =* 

08933 * badassertion 

089|É|$§f========================================================================*/ 

08935 PUBLIC void bad_assertion(file, line, what) 

08936 char *file; 

08937 int lj,ne; 

08938 char *what; 

08939 { 

08940 printf("panic at %s(%d): assertion \"%s\" failedVt", file, line, what); 

08941 panic(NULL, NO_NUM); 

08942 } 

08944/*=====================================================* 

08945 * badcompare 

08946 *=========== =—-=■ ===== =■--—--=--- ==*/ 

08947 PUBLIC void bad compare(file, line, lhs, what, rhs) 

08948 char *file; 

08949 int line; 

08950 int lhs; 

08951 char* what; 

08952 int rhs; 

08953 { 

08954 printf("panic at %s(%d): compare (%d) %s (%d) failed\n", 

08955 file, line, lhs, what, rhs); 

08956 panic(NULL, NO_NUM); 

08957 } 

08958 #endif /* DEBUG */ 


src/kemel/driver.h 


09000 /* Tipos y constantes compartidos entre el código de controlador de disp. genérico 

09001 * Y dependiente del dispositivo. 

09002 */ 

09003 

09004 #include <minix/callnr.h> 

09005 #include <minix/com.h> 

09006 #include "proc.h" 

09007 #include <minix/partition.h> 

09008 

09009 /* Info. y puntos de entrada al código dependiente del dispositivo. */ 

09010 struct driver { 

09011 PROTOTYPE( char *(*dr_name), (void) ); 

09012 PROTOTYPE( int (*dr open), (struct driver *dp, message *m_ptr) ); 

09013 PROTOTYPE( int (*dr cióse), (struct driver *dp, message *m_ptr) ); 

09014 PROTOTYPE( int (*dr ioctl), (struct driver *dp, message *m_ptr) ); 

09015 PROTOTYPE( struct device *(*dr_prepare), (int device) ); 

09016 PROTOTYPE( int (*dr schedule) , (int proc nr, struct iorequest s *request) ); 
09017 PROTOTYPE( int (*dr finish), (void) ); 

09018 PROTOTYPE( void (*dr cleanup), (void)); 

09019 PROTOTYPE( void (*dr geometry), (struct partition *entry) ); 

09020 }; 

09021 

09022 #if (CHIP = INTEL) 

09023 

09024 /* Núm. bytes accesibles por DMA antes de taparse con frontera de 64K: */ 
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09025 #defme dma_bytes_left(phys) \ 

09026 «unsigned) (sizeof(int) = 2 ? 0 : 0x10000) -(unsigned) «phys) & OxFFFF» 
09027 

09028 #endif /* CHIP == INTEL */ 

09029 

09030 /* 8ase y tamaño de una partición en bytes. */ 

09031 struct, device { 

09032 unsigned long dv_base; 

09033 unsigned long dv_sizej 

09034 }; 

09035 

09036 #define NIL_DEV «struct device *) 0) 

09037 

09038 /* Funciones definidas por driver.c: */ 

09039 _PROTOTYPE( void driver task, (struct driver *dr)); 

09040 _PROTOTYPE( int do rdwt, (struct driver *dr, message *m_ptr)); 

09041 _PROTOTYPE( int do=vrdwt, (struct driver *dr, message *m_ptr)) j 

09042 _PROTOTYPE( char *no_name, (void) ); 

09043 _PROTOTYPE( int do_nop, (struct driver *dp, message *m_ptr) ); 

09044 _PROTOTYPE( int nop_finish, (void) ); 

09045 _PROTOTYPE( void nop cleanup, (void)); 

09046 _PROTOTYPE( void clock mess, (int ticks, watchdog t fuñe)); 

09047 _PROTOTYPE( int do_diocntl, (struct driver *dr, message *m_ptr)); 

09048 

09049 /* parámetros para la unidad de disco. */ 

09050 #define SECTOR SIZE 512 /* tamaño sector físico en bytes */ 

09051 #define SECTOR=SHIFT 9 /* para división */ 

09052 #define SECTORMASK 511 /* Y residuo*/ 

09053 

09054 /* Tamaño del buffer de DMA en bytes. */ 

09055 #define DMA_BUF_SIZE(DMA_SECTORS * SECTOR_SIZE) 

09056 

09057 #if (CHIP = INTEL) 

09058 

09059 #else 
09060 

09061 #endif 

09062 extern phys_bytes tmp_phys 


extern u8_t *tmp_buf; /* el buffer de DMA */ 
extern u8_t tmp_buf[l j /* el buffer de DMA */ 
/* dir. fís. de buffer DMA */ 
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09100 /* Este archivo contiene interfaz de canto disp. indep. del disp. 

09101 * Autor: Kees J. Bot. 

09102 * 

09103 * Los controladores reconocen estas operaciones (usando formato mens. m2): 

09104 * 

09105 * m type DEVICE PROC_NR COUNT POSITION ADRRESS 

09106 * 

09107 * DEV OPEN 1 disp. 1 # proc. I 1 1 1 

09108 * 1-+-+-+-+-+.-1 

09109 * 1 DEV_CLOSE 1 disp. I#proc. 1 I I I 

09110 * 1-+-+-+-+-+_1 

09111*1 DEV READ I disp. I # proc. 1 bytes I dist. 

09112 * 1-+-+-+-+-+- 

09113*1 DEV_WRITE I disp. l#proc. I bytes 1 disto I ap. buf 
09114 * 1-+-.-+-+-+-+- 


I ap. buf 
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09115 * ISCATTERED IOI disp. I # proc. I solic. I I ap. iov I 

09116 * 

09117 * I OEV IOCTLI disp. I # proc. I cód fuñe I I ap. buf I 

09118 * 

09119 * 

09120 * Este archivo contiene un archivo de entrada: 

09121 * 

09122 * driver task: invocado por entrada de tarea dependo disp. 

09123 * 

09124 * 

09125 * Construido 92/04/02 por Kees J. Bot con viejo AT wini y cont. disquete. 

09126 */ 

09127 

09128 #include "kemel.h" 

09129 #include <sys/ioctl.h> 

09130 #include "driver.h" 

09131 

09132 #defme BUFEXTRA 
09133 

09134 /* Apartar espacio para variables. */ 

09135 PRIVATE u8_t buffer[(unsigned) 2 * DMA BUF SIZE + BUF EXTRAj; 

09136 u8t*tmpbuf; /* el buffer DMA después */ 

09137 phYS bytes tmpjhys; /* dir. fís. de buffer DMA */ 

09138 

09139 FORWARD PROTOTYPE( void inhbuffer, (void) ); 

09140 

09141 /*= - ========== - ===========-= -■= * 

09142 * driver task * 

09143 *========================================================*/ 

09144 PUBLIC void driver taSk(dp) 

09145 struct driver *dp; /* Puntos de entrada dependientes del disp. *1 

09146 { 

09147 /* Programa principal de cualquier tarea de controlador de dispositivo. */ 

09148 

09149 int r, caller, proc nr; 

09150 message mess; 

09151 

09152 init_buffer(); /* Obtener un buffer de DMA. */ 

09153 

09154 /* Este es el ciclo principal de la tarea de disco. Espera un mensaje, 

09155 * lo ejecuta y envía una respuesta. 

09156 */ 

09157 

09158 while (TRUE) { 

09159 /* Primero espera solicitud de leer o escribir bloque de disco. */ 

09160 receive(ANY, &mess); 

09161 

09162 caller = mess.m_source' 

09163 proc nr = mess.PROC NR; 

09164 

09165 switch (caller) { 

09166 case HARDWARE: 

09167 /* Interrupción remanente. */ 

09168 continué; 

09169 case FS PROC NR: 

09170 -/* El único invocador legítimo. */ 

09171 break; 

09172 default: 

09173 printf("%s: got message from %d\n", (*dp->dr_name)(), caller); 

09174 continué; 
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09175 } 

09176 

09177 /* Ahora realizar el trabajo. */ 

09178 switch(mess.mtype) { 

09179 case DEV OPEN: r = (*dp->dr open)(dp, &mess); break; 

09180 case DEVJXOSE: r= (*dp->dr cióse) (dp, &mess); break; 

09181 case DEV IOCTL: r = (*dp->dr ioctl)(dp, &mess); break; 

09182 

09183 case DEV_READ: 

09184 case DEV WRITE: r = do rdwt(dp, &mess); break; 

09185 

09186 case SCATTEREDJO: r = do_vrdwt(dp, &mess); break; 

09187 default: r = EINVAL; break; 

09188 } 

09189 

09190 I* Aseo de estado remanente. */ 

09191 (*dp->dr cleanup) (); 

09192 

09193 /* Por último, preparar y enviar mensaje de respuesta. */ 

09194 mess.m type = TASK REPLY; 

09195 mess.REP PROC NR = proc nr; 

09196 

09197 mess.REP STATUS = r; /* # bytes transferidos o cód. error */ 

09198 send(caller, &mess); /* enviar respuesta a invocador */ 

09199 } 

09200 } 

09202/*====================================================* 

09203 * initjmffer * 

09204*========================================================*/ 

09205 PRIVATE void init buffer() 

09206 { 

09207 /* Escoger buffer seguro para usar en transí. DMA. También 

09208 * puede usarse para leer tablas de particiones, etc. Su dirección 

09209 * absoluta es 'tmp_phys', la dirección normal es 'tmpbuf. 

09210 */ 

09211 

09212 tmp buf = buffer; 

09213 tmpjihys = vir2phys(buffer); 

09214 

09215 if (tmp phys =0) panic("no DMA buffer", NO_NUM); 

09216 

09217 if (dma_bytes_left(tmp_phys) < DMA BUF SIZE) { 

09218 /* la. mitad de bufo cruza un limo de 64K, no acceso por DMA ahí. */ 

09219 tmp buf += DMA BUF_SIZE; 

09220 tmp_phys += DMA_BUF_SIZE; 

09221 } 

09222 } 

092§|íp================================* 

09225 * do rdwt * 

09227 PUBLIC int do_rdwt(dp, m_ptr) 

09228 struct driver *dp; /* ptos. entrada dependo del disp. */ 

09229 message *m_ptr; /* apuntador p/leer o escribo mensaje */ 

09230 { 

09231 /* Ejecutar una sola solicitud de leer o escribir. */ 

09232 struct iorequest_s ioreq; 

09233 intr; 

09234 
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09235 if (m_ptr->COUNT <= 0) retum(EINVAL); 

09236 

09237 if «*dp->dr_prepare) (m_ptr->DEVICE) = NILDEV) retum(ENXIO); 

09238 

09239 ioreq.io request = mjptr->m_type; 

09240 ioreq.io buf= rnj)tr->ADDRESS; 

09241 ior~q.io_position = m ptr->POSITION; 

09242 ioreq.ionbytes = m_ptr->COUNT; 

09243 

09244 r = (*dp->dr schedule) (m_ptr->PROC NR, &ioreq); 

09245 

09246 if (^OK) (void) (*dp->dr_finish)()j 
09247 

09248 r = ioreq.io_nbytes; 

09249 retum(r < 0 ? r : m_ptr->COUNT -r); 

09250 } 

092^====================—= 

09253 * dovrdwt 

09254 *===== . ===== . . . = 

09255 PUBLIC int do_vrdwt(dp, m ptr) 

09256 struct driver *dp; /* ptas. entrada dependo del disp. */ 

09257 message *m_ptr; /* apunto p/leer o escribo mensaje */ 

09258 { 

09259 /* Obtener un vector de solicitudes de E/S. Atender solicitudes una por una. 

09260 * Devolver la situación en el vector. 

09261 */ 

09262 

09263 struct iorequest_s *iop; 

09264 static struct iorequest s ioveC[NR IOREOS]; 

09265 physbytes iovec_physj 
09266 unsigned nrrequests; 

09267 int requestj 
09268 intr; 

09269 physbytes user_iovec_phys; 

09270 

09271 nrrequests = m_ptr->COUNT; 

09272 

09273 if (nr requests > sizeof iovec / sizeof iovec[0]) 

09274 panic("FS passed toa big an 1/0 vector", nr_requests); 

09275 

09276 iovec_phys = vir2phys(iovec); 

09277 user iovec_phys = numap(m_ptr->PROC_NR, (vir_bytes) m_ptr->ADDRESS, 
09278 (vir bytes) (nr requests * sizeof iovec[0]»; 

09279 

09280 if (user_iovec_phys == 0) 

09281 panic("FS passed abad 1/0 vector", (int) m_ptr->ADDRESS); 

09282 

09283 phys_copy(user_iovec_phys, iovec_phys, 

09284 (phys bytes) nr requests * sizeof iovec[0]); 

09285 

09286 if «*dp->dr_prepare) (m_ptr->DEVICE) = NIL DEV) retum(ENXIO); 

09287 

09288 for (request = 0, iop = iovecj request < nr_requests; request++, iop++) { 

09289 if «r = (*dp->dr schedule) (m_ptr->PROC NR, iop») != OK) break; 

09290 } 

09291 

09292 if (r == OK) (void) (*dp->dr finish) (); 

09293 

09294 phys_copy(iovec_phys, user iovec_phys, 
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09295 (phys bytes) nrrequests * sizeof iovec[0]); 

09296 retum(OK); 

09297 } 

09300 * no j a me 

093<flt*i|f¡===,====================================================== 

09302 PUBLIC char *no_name() 

09303 { 

09304 /* Si no hay nombre específico para el dispositivo. */ 

09305 

09306 return(tasktab[proc number(proc_ptr) + NR_TASKS].name); 

09307 } 

09309 /*============================================ 

09310 * do nop 

09311 *==========—=======— 

09312 PUBLIC int do nop(dp, m_ptr) 

09313 struct driver *dp; 

09314 message *m_ptr; 

09315 { 

09316 /* Nada ahí, o nada que hacer. */ 

09317 

09318 switch (m_ptr->m type) { 

09319 case DEV_OPEN: retum(ENODEV); 

09320 case DLV CLOSE: retum(OK); 

09321 case DEV IOCTL: retum(ENOTTY); 

09322 default: retum(EIO); 

09323 } 

09324 } 

09326 /*============================================================= 

09327 * nopfmish 

093 ^ ."~: * A n G" ■■■ : .. . 

09329 PUBLIC int nop_fmishO 

09330 { 

09331 /* Nada que terminar, dp->dr_schedule hizo todo el trabajo. */ 

09332 retum(OK); 

09333 } 

093|Ü»============================================================= 

09336 * nop cleanup 

09337 * 

09338 PUBLIC void nop cleanupO 

09339 { 

09340 /* Nada que asear. */ 

09341 } 

09343 /»= -= ======== - ===== - - 

09344 * clockjness 

09345 *—==—========—====—— 

09346 PUBLIC void dock mess(ticks, fuñe) 

09347 int ticks; -/* cuántos tics de reloj esperar */ 

09348 watchdog t fuñe; /* función que llamar al vencer tiempo */ 

09349 { 

09350 /* Enviar un mensaje a la tarea del reloj. */ 

09351 

09353 

09354 mess.m type = SET ALARM; 
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09355 mess.CLOCKPROCNR = proc_number(proc_ptr); 

09356 mess.DELTATICKS = (long) ticksj 
09357 mess.FUNCTOCALL = (sighandler_t) fuñe; 

09358 sendrec(CLOCK, &mess); 

09359 } 

09361 /*=== = ========================== = =================== = ========== 

09362 * do diocntl 

09363 * — ■■■■ - ==== — ============= == ======== = ====== == ======= = 

09364 PUBLIC int do_diocntl(dp, m_ptr) 

09365 struct driver *dp; 

09366 message *m_ptr; /* apuntador a solicitud ioctl */ 

09367 { 

09368 /* Ejecutar solicitud de establecer/obtener partición. */ 

09369 struct device *dv; 

09370 phys_bytes user_phys, entry_phys; 

09371 struct partition entry; 

09372 

09373 if (m_ptr->REQUEST != DIOCSETP && m_ptr->REQUEST != DIOCGETP) retum(ENOTTY); 
09374 

09375 /* Descodificar parámetros del mensaje. */ 

09376 if ((dv = (*dp->dr_prepare)(m_ptr->DEVICE» = NIL DEV) retum(ENXIO); 

09377 

09378 user_phys = numap(m_ptr->PROC_NR, (vir_bytes) m_ptr->ADDRESS, sizeof(entrY)); 

09379 if (user_phys = 0) return(EFAULT); 

09380 

09381 entry_phys = vir2phys(&entrY); 

09382 

09383 if (m_ptr->REQUEST = DIOCSETP) { 

09384 /* Copiar sólo esta entrada de la tabla de particiones. */ 

09385 phys_copy(user_phys, entry_phys, (phys_bytes) sizeof(entr)); 

09386 dv->dv_base = entry.base; 

09387 dv->dv_size = entry. size; 

09388 } else { 

09389 /* Devolver una entrada de tabla de partic. y geometría de la unidad. */ 

09390 entry .base = dv->dv_base; 

09391 entry.size = dv->dv_size; 

09392 (*dp->dr_geometry)(&entrY); 

09393 phys_copy(entry_phys, user_phys, (phys_bytes) sizeof(entr)); 

09394 } .' 

09395 retum(OK); 

09396 } 


src/kemel/drvlib.h 


09400 /* Definiciones de controlador de disp. IBM. Autor: Kees J. 

Bot 

09401 * Dic. 7, 1995 

09402 */ 

09403 

09404 #include <ibm/partition.h> 

09405 

09406 _PROTOTYPE( void partition, (struct driver *dr, int device, int style)); 

09407 

09408 /* Organización de la tabla de parámetros de BIOS. */ 

09409 #define bp_cylinders(t) (* (ul6_t *) (&(t)[0])) 
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09410 

09411 

09412 

09413 

09414 

09415 

09416 

09417 

09418 

09419 

09420 

09421 

09422 

09423 

09424 


#defme bp_heads(t)(* (u8_t *) (&(t)[2])) 

#defme bp_reduced_wr(t) (* (ul6_t *) (&(t)[3])) 

#defme bp_precomp(t) (* (ul6_t *) (&(t)[5])) 

#define bp_max_ecc(t) (* (u8_t *) (&(t) [7])) 

#define bp_ctlbyte(t)(* (u8_t *) (&(t)[8])) 

#defme bp_landingzone(t) (* (ul6_t *) (&(t)[12])) 

#defme bp_sectors(t) (* (u8_t *) (&(t)[141)) 


#defme DE VPERDR1 VE (1 + NRPART1T10NS) 

#defme MINORhdla 128 

#defme MlNOR_fdOa (28«2) 

#defme PFLOPPY 0 

#defíne P PR1MARY 1 

#defme PSUB 2 
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09500/* Funciones de utilería de cont. disp. IBM. 

09501 * 

: Punto de entrada: 

: partition: dividir un disco según tabla(s) de particiones que ti< 


Autor: Kees J. Bot 
Dic. 7, 1995 


09502 

09503 

09504 

09505 

09506 

09507 

09508 

09509 

09510 

09511 

09512 

09513 

09514 

09515 

09516 

09517 

09518/’ 

09519 * 

09520 * 

09521 

09522 

09523 

09524 

09525 

09526 


#include "kemel.h" 
#include "driver.h" 
#include "drvlib.h" 


FORWARD _PROTOTYPE( void extpartition, (struct driver *dp, int extdev, 

unsigned long extbase)); 

FORWARD _PROTOTYPE( int get_part_table, (struct driver *dp, int device, 
unsigned long offset, struct part_entry *table)); 

FORWARD _PROTOTYPE( void sort, (struct part entry *table)); 


partition 


PUBLIC void partition(dp, device, style) 

struct driver *dp;/* ptos. entrada dependo del disp. */ 

int device; /* dispositivo que dividir */ 

int style; /* estilo de partic.: disquete, primario, sub. */ 


/* Esta rutina se llama en la. apertura p/inicializar tablas 
09527 * de particiones de un disp. Se asegura de que cada partición 
09528 * esté dentro de los límites del disp. Dependiendo del estilo de partic., 
09529 * estamos haciendo particiones de disquete, primarias o subpartic. 
09530 * Sólo las primarias están ordenadas, porque se comparten 
09531 * con otros sistemas operativos que esperan esto. 

09532 */ 

09533 struct part_entry table[NR_PARTlT10NS], *pe; 

09534 int disk, par; 
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09535 struct device *dv; 

09536 unsigned long base, limit, part_limit; 

09537 

09538 /* Obtener geometría del dispositivo por dividir. */ 

09539 if ((dv = (*dp->dr_prepare)(device)) == NIL_DEV 11 dv->dv_size = 0) retum; 

09540 base = dv->dv_base » SECTOR_SHIFT; 

09541 limit = base + (dv->dv_size » SECTOR_SHIFT); 

09542 

09543 /* Leer la tabla de particiones piel dispositivo. */ 

09544 if (!get_part_table(dp, device, 0L, table)) retum; 

09545 

09546 / * Calcular el núm. de dispositivo de la la. partición. */ 

09547 switch (style) { 

09548 case P FLOPPY: 

09549 device+=MINOR_fd0a; 

09550 break; 

09551 case PPRIMARY: 

09552 sort(table); /* ordenar tabla de partic. primaria */ 

09553 device 4=1; 

09554 break; 

09555 case P_SUB: 

09556 disk = device IDEVPERDRIVE; 

09557 par = device % DEV PER DRIVE -1; 

09558 device = MINORJidla + (disk * NR_PARTITIONS + par) * NR_P ARTITIONS; 

09559 } 

09560 

09561 /* Encontrar un arreglo de dispositivos. */ 

09562 if ((dv = (*dp->dr_prepare) (device)) = NIL_DEV) retum; 

09563 

09564 /* Establecer geometría de particiones con base en la tabla. */ 

09565 for (par = 0; par < NR_P ARTITIONS; par++, dv++) { 

09566 /* Encoger partición pique quepa en dispositivo. */ 

09567 pe = &table[par]; 

09568 part_limit = pe->lowsec + pe->size ; 

09569 if (part_limit < pe->lowsec) part_limit = limit; 

09570 if (part_limit > limit) part_limit = limit; 

09571 if (pe->lowsec < base) pe->lowsec = base; 

09572 if (part_limit < pe->lowsec) part_limit = pe->lowsec; 

09573 

09574 dv->dv_base = pe->lowsec « SECTOR SHIFT; 

09575 dv->dv_size = (part limit pe->lowsec)« SECTOR_SHIFT; 

09576 

09577 if (style = P PRIMARY) { 

09578 /* Cada partic. primaria de Minix puede subdividirse. */ 

09579 if (pe->sysind = MINIXPART) 

09580 partition(dp, device + par, P_SUB); 

09581 

09582 /* Una partic. extendida tiene partic. lógicas, */ 

09583 if (pe->sysind = EXTPART) 

09584 extpartition(dp, device + par, pe->lowsec); 

09585 } 

09586 } 

09587 } 

09590 /*== ■ =============== = ===================== = =============== = == = = == * 

09591 * extpartition * 

09592 * ■ ■ ^ ========= ^^ === = = ■ = === =============== == ===============♦/ 

09593 PRIVATE void extpartition(dp, extdev, extbase) 

09594 stmct driver *dp; /* ptos. entrada dependo del disp. */ 
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09595 int extdev; /* partición extendida que explorar */ 

09596 unsigned long extbase; /* disto sector de la base de la partic. ext. */ 

09597 { 

09598 /* Las partic. extendidas no pueden ignorarse porque la gente gusta de mover 

09599 * archivos entre partic. de DOS. Evite leer esto, no es divertido. 

09600 */ 

09601 struct part entry table[NR_PARTITIONS], *pe; 

09602 int subdev, disk, par; 

09603 struct device *dv; 

09604 unsigned long offset, nextoffset; 

09605 

09606 disk = extdev / DEV_PER_DRIVE; 

09607 par = extdev % DEV PER DRIVE -1; 

09608 subdev = MINOR_hdla + (disk * NR_PARTITIONS + par) * NR_P ARTITIONS ; 

09609 

09610 offset = 0; 

09611 do { 

09612 if (!get_part_table(dp, extdev, offset, table)) retum; 

09613 sort(table); 

09614 

09615 /* La tabla debe contener una partic. lógica y opcionalmente otra partic. 

09616 * extendida. (Es una lista enlazada.) 

09617 */ 

09618 nextoffset = 0 ; 

09619 for (par = 0 ; par < NR_PARTITIONS ; parH-) { 

09620 pe = &table[par]; 

09621 if (pe->sysind = EXT PART) { 

09622 nextoffset = pe->lowsec; 

09623 } else 

09624 if (pe->sysind != NO PART) { 

09625 if ((dv = (*dp->dr_prepare) (subdev)) == NIL_DEV) retum; 

09626 

09627 dv->dv_base = (extbase + offset 

09628 + pe->lowsec)« SECTOR_SHIFT; 

09629 dv->dv_size = pe->size« SECTOR_SHIFT; 

09630 

09631 /* ¿No más dispositivos? */ 

09632 if (++subdev % NR_PARTITIONS = 0) retum; 

09633 } 

09634 } 

09635 } while ((offset = nextoffset) != 0)j 
09636 } 

09639 /♦ ====== = ======= = ======== = === = == 


09640 * get_part_table 

09641 * . ■, . = ======= ^ = ^=^ === — ■ - - - —■■-- == ========.======== == ======== 

09642 PRIVATE int get_part_table(dp, device, offset, table) 

09643 struct driver *dp; 

09644 int device; 

09645 unsigned long offset; /* disto de sector a la tabla */ 

09646 struct part_entry *table; /* cuatro entradas */ 

09647 { 

09648 /* Leer la tabla de particiones del dispositivo, devolver true si no 

09649 * hubo errores. 

09650 */ 

09651 message mess; 

09652 

09653 mess.DEVICE = device ; 

9654 mess.POSITION = offset« SECTOR_SHIFT; 
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09655 mess.COUNT = SECTOR_SIZEj 
09656 mess.ADDRESS = (char *) tmp_bufj 
09657 mess.PROCNR = proc_number(proc_ptr); 

09658 mess.m_type = DEVREAD; 

09659 

09660 if (do_rdwt(dp, &mess) != SECTOR_SIZE) { 

09661 printf("%s: can't read partition table\n", (*dp->dr_name)()); 

09662 retum 0; 

09663 } 

09664 if (tmp_buf[510] !=0x55 11 tmp_buf[511] != OxAA) { 

09665 /* Tabla de particiones no válida. */ 

09666 retum 0; 

09667 } 

09668 memcpy(table, (tmp buf + PARTTABLEOFF), NR_P ARTITIONS * sizeof(table[0])); 
09669 retum 1; 

09670 } 


09673 

09674 

09675 

09676 

09677 

09678 

09679 

09680 

09681 

09682 

09683 

09684 

09685 

09686 

09687 

09688 

09689 

09690 

09691 

09692 


/*= 


PRIVATE void sort(table) 
struct part_entry *table; 

{ 

/* Ordenar una tabla de particiones. */ 
struct part_entry *pe, tmp; 
int n = NR_P ARTITION S; 


do { 

for (pe = table; pe < table + NR_PARTITIONS-l; pe++) { 
if (pe[0] .sysind = NOPART 

11 (pe[0] .lowsec >pe[l] .lowsec 

&& pe[l] .sysind != NO PART)) { 
tmp = pe[0]j pe[0] = pe[ 1 ]j pe[l] = tmp; 

} 

} 

} while (-n > 0); 

} 
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09700 /* Este archivo contiene la parte dependiente del dispositivo 

09701 * de los controladores para los archivos especiales siguientes: 

09702 * /dev/null -dispositivo nulo (sumidero de datos) 

09703 * /dev/mem -memoria absoluta 

09704 * /dev/kmem -memoria virtual del kemel 

09705 * /dev/ram -disco en RAM 

09706 * 


09707 * El archivo contiene un punto de entrada: 

09708 * 

09709 * mem_task: entrada principal cuando se inicia el sistema 

09710 * 

09711 * Cambios: 

09712 * 20 abr 1992 por Kees J. Bot: división depend/indep del disp. 

09713 */ 

09714 
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09715 #include "kemel.h" 

09716 #include "driver.h" 

09717 #include <sys/ioctl.h> 

09718 

09719 #define NR_RAMS 4 /* núm. de dispositivos tipo RAM */ 

09720 

09721 PRIVATE struct -evice m_geom[NR_RAMS]; /* Base y tamo de cada disco RAM */ 

09722 PRIVATE int m_devicej /* dispositivo actual */ 

09723 

09724 FORWARD _PROTOTYPE( struct device *m_prepare, (int device)); 

09725 FORWARD PROTOTYPE( int m schedule, (int proc nr, struct iorequest s *iop)); 

09726 FORWARD =PROTOTYPE( int m do open, (struct driver *dp, message *m_ptr)); 

09727 FORWARD PROTOTYPE( void m init, (void)); 

09728 FORWARD =PROTOTYPE( int m ioctl, (struct driver *dp, message *m_ptr)); 

09729 FORWARD _PROTOTYPE( void m geometry, (struct partition *entry)); 

09730 

09731 

09732 /* Puntos de entrada a este controlador. */ 

09733 PRIVATE struct driver m dtab = { 

09734 no_name, /* nombre del dispositivo actual */ 

09735 m_do_open, /* abrir o montar */ 

09736 do_nop, /* nada al cerrar */ 

09737 m_ioctl, /* especificar geometría de disco en RAM */ 

09738 m_prepare, /* preparar para E/S en disp. secundario dado */ 

09739 m_schedule, /* realizar E/S */ 

09740 nop_finish, /* schedule hace el trabajo, no hace falta pensar */ 

09741 nop_cleanup, /* no hay nada sucio */ 

09742 m_geometry, /* "geometría" del dispositivo de memoria */ 

09743 }; 

09744 

09745 

09746 /*============================================ = ============= 

09747 * mem task * 

09748 *============================= == =============== == ======= == 

09749 PUBLIC void mem_task() 

09750 { 

09751 mJnitO; 

09752 driver_task(&m_dtab); 

09753 } 

09756 /*=========== = ================================== = ======= = ===== 

09757 * m_prepare * 

09758 *===-- ^ ========= ^^ === =.,, == == =============== === ======= == 

09759 PRIVATE stmct device *m_prepare(device) 

09760 int device; 

09761 { 

09762 /* Preparar para E/S en dispositivo. */ 

09763 

09764 if (device <011 device >= NR RAMS) retum(NIL_DEV); 

09765 m_device = device; 

09766 

09767 retum(&m_geom[device]); 

09768 } 


09772 * m schedule 

09773 *= 

9774 


PRIVATE int m_schedule(proc_nr, iop) 
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09775 int proc_nr; /* proceso que solicita */ 

09776 struct iorequest_s *iop; /* apunto a solic. de leer o escribir */ 

09777 { 

09778 /* Leer o escribir /dev/null, /dev/mem, /dev/kmem o /dev/ram. */ 

09779 

09780 int device, count, opcode; 

09781 phys'_bytes mem_phys, user _phys; 

09782 struct device *dv; 

09783 

09784 /* Tipo de solicitud. */ 

09785 opcode = iop->io_request & OPTIONALIO; 

09786 

09787 /* Obtener núm. de disp. secundario y verificar /dev/null. */ 

09788 device = m_device; 

09789 dv = &m_geom[devicel; 

09790 

09791 /* Determinar dirección de origen o destino de datos. */ 

09792 user_phys = numap(proc_nr, (vir_bytes) iop->io_buf, 

09793 (vir bytes) iop->io_nbytes); 

09794 if (user_phys — 0) retum(iop->io_nbytes = EINVAL); 

09795 

09796 if (device == NULL DEV) { 

09797 /* /dev/null: Agujero negro. */ 

09798 if (opcode = DEV WRITE) iop->io_nbytes = 0; 

09799 count = 0; 

09800 } else { 

09801 /* /dev/mem, /dev/kmem o /dev/ram: Verificar EOF */ 

09802 if (iop->io_position >= dv->dv_size) retum(OK); 

09803 count = iop->io_nbytes; 

09804 if (iop->io_position + count > dv->dv_size) 

09805 count = dv->dv_size -iop->io_position; 

09806 } 

09807 

09808 /* Preparar 'mem_phys' para /dev/mem, /dev/kmem o /dev/ram */ 

09809 mem_phys = dv->dv_base + iop->io_position; 

09810 

09811 /* Reservar por adelantado núm. de bytes por transferir. */ 

09812 iop->io_nbytes -= count; 

09813 

09814 if (count = 0) retum(OK); 

09815 

09816 /* Copiar los datos. */ 

09817 if (opcode = DEV READ) 

09818 phys_copy(mem_phys, user_phys, (phys_bytes) count); 

09819 else 

09820 phys_copy(user_phys, mem_phys, (phys_bytes) count); 

09821 

09822 retum(OK); 

09823 } 

09826 /*=== = == = ========== = ===== === -= == ===== = ======= === = 

09827 * m do open 

09828 * ^ --: .^- =============== = ==== ^ = = ======= = ===== === = 

09829 PRIVATE int m_do_open(dp, m_ptr) 

09830 struct driver *dp; 

09831 message *m_ptr; 

09832 { 

09833 /* Revisar núm. de dispositivo al abrir. Dar privilegios de E/S a un proceso 

09834 * que abre /dev/mem o /dev/kmem. 
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09835 */ 

09836 

09837 if (m_prepare(m_ptr->DEVICE) = NILDEV) retum(ENXIO); 

09838 

09839 if (mdevice = MEM DEV 11 mdevice == KMEM DEV) 

09840 enable_iop(proc_addr(m_ptr->PROC_NR)); 

09841 

09842 retum(OK); 

09843 } 

09846 /♦==== === ===== ======= = ====== = ==== 

09847 * m_init * 

09848 *== === ===== = = = = == = = == == = = === = = = ====== = == === === == 

09849 PRIVATE void m_init() 

09850 { 

09851 /* Inicializar esta tarea. */ 

09852 extern int _end; 

09853 

09854 m_geom[KMEM_DEV] .dv base = vir2phys(0); 

09855 m geom[KMEM DEV] ,dv_size = vir2phys(&_end); 

09856 

09857 #if (CHIP = INTEL) 

09858 if (!protected_mode) { 

09859 m_geom[MEM_DEV] .dv size = 0x100000; /* 1M p/sistemas 8086 */ 

09860 } else { 

09861 #if WORD SIZE = 2 

09862 m_geom[MEM_DEV] .dv size = 0x1000000; /* 16M p/sistemas 286 */ 

09863 #else 

09864 m_geom[MEM_DEV] ,dv_size = OxFFFFFFFF; /* 4G-1 para sistemas 386 */ 

09865 #endif 
09866 } 

09867 #endif 
09868 } 

09871 /*============================================== = ========= 

09872 * mjoctl * 

09873 *============================= == =============== == ======= == 

09874 PRIVATE int m_ioctl(dp, m_ptr) 

09875 struct driver *dp; 

09876 message *m_ptr; /* apunto para leer o escribir mensaje */ 

09877 { 

09878 /* Establecer parámetros para uno de los discos en RAM. */ 

09879 

09880 unsigned long bytesize; 

09881 unsigned base, size; 

09882 struct memory *memp; 

09883 static struct psinfo psinfo = { NR_TASKS, NR_PROCS, (vir_bytes) proc, 0, 0 }; 

09884 phys_bytes psinfo_phys; 

09885 

09886 switch (m_ptr->REQUEST) { 

09887 case MIOCRAMSIZE: 

09888 /* FS establece el tamaño del disco en RAM.*/ 

09889 if (m_ptr->PROC_NR != FS_PROC_NR) retum(EPERM); 

09890 

09891 bytesize = m_ptr->POSITION * 8LOCK SIZE; 

09892 size = (bytesize + CLICK SHIFT-1) » CLICK SHIFT; 

09893 

09894 /* Encontrar trozo de memoria en el que quepa el disco en RAM. */ 
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09895 memp= &mem[NR_MEMS]; 

09896 while «—memp) ->size < size) { 

09897 if (memp = mem) panic("RAM disk is toa big", NO NUM); 

09898 } 

09899 base = memp->base; 

09900 memp->base += size; 

09901 roemp->size -= size; 

09902 

09903 m_geom[RAM_DEV] ,dv_base = (unsigned long) base « CLICKSHIFT; 

09904 m_geOm[RAM_DEV] .dv size = bytesize; 

09905 break; 

09906 case MIOCSPSINFO: 

09907 /* MM o FS fijan la dirección de su tabla de procesos. */ 

09908 if (m_ptr->PROC_NR = MM_PROC_NR) { 

09909 psinfo.mproc = (vir bytes) m_ptr->ADDRESS; 

09910 } else 

09911 if (m_ptr->PROC_NR = FS_PROC_NR) { 

09912 psinfo.fproc = (vir bytes) m_ptr->ADDRESS; 

09913 } else { 

09914 retum(EPERM); 

09915 } 

09916 break; 

09917 case MIOCGPSINFO: 

09918 /* El programa ps quiere direcciones de tabla de procesos. */ 

09919 psinfo_phys = numap(m_ptr->PROC_NR, (vir bytes) m_ptr->ADDRESS, 

09920 sizeof(psinfo)); 

09921 if (psinfo_phys = 0) retum(EFAULT); 

09922 phys_copy(vir2phys(&psinfo), psinfo_phys, (phys_bytes) sizeof(psinfo)); 

09923 break; 

09924 default: 

09925 retum(do_diocntl(&m_dtab, m_ptr)); 

09926 } 

09927 retum(OK); 

09928 } 

09931 /*======================= = ================ = ======== == 

09932 * m geometry 

09933 * = = = = == === = = = = == = = = = = == === = = ===== = = = ====== = === = 

09934 PRIVATE void m geometry(entry) 

09935 struct partition *entry; 

09936 { 

09937 /* Disp. de memoria no tienen geometría, pero el mundo exterior insiste. */ 

09938 entry->cylinders = (m_geom[m_device] .dv size » SECTOR SHIFT) / (64 * 32); 

09939 entry->heads = 64; 

09940 entry->sectors = 32; 

09941 } 
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10000 

10001 

10002 

10003 

10004 

10005 

10006 

10007 

10008 

10009 

10010 
10011 
10012 

10013 

10014 

10015 

10016 

10017 

10018 

10019 

10020 
10021 
10022 

10023 

10024 

10025 

10026 

10027 

10028 

10029 

10030 

10031 

10032 

10033 

10034 

10035 

10036 

10037 

10038 

10039 

10040 

10041 

10042 

10043 

10044 

10045 

10046 

10047 

10048 

10049 

10050 

10051 

10052 

10053 

10054 


* Se pueden compilar varios controladores Winchester 
diferentes en el kemel, pero sólo uno puede ejecutarse. Ése st 

* escoge aquí usando la variable de arranque ’hd'. 


#include "kernel.h" 
#include "driver.h" 


#if ENABLE WINI 


/*wini.c -escoger controlador Winchester 
Mayo 28, 1994 


Autor: Kees J. 


/* Correspondencia ei 
struct hdmap { 

task_t *task; 

} hdmap[ ] = { 

#if ENABLEATWINI 
{"at", at_winchester_task 

#endif 

#if ENABLEBIOSWINI 
{"bios", bios_winchester_task 

#endif 

#if ENABLEESDIWINI 
{"esdi", esdi_winchester_task 

#endif 

#if ENABLEXTWINI 
{"xt", xt_winchester_task 

#endif 


e nombre de controlador y función de ta 


winchester_task 


PUBLIC void winchester_task() 

{ 

/* Invocar tarea Winchester predeterminada o escogida. */ 
char *hd; 

stmct hdmap *map; 
hd = k_getenv("hd"); 

for (map = hdmap; map < hdmap + sizeof(hdmap)/sizeof(hdmap[0]); map++) { 
if (hd = NULL | | strcmp(hd, map->name) = 0) { 

/* Ejecutar tarea Winchester escogida. */ 

(*map->task) (); 


} 

panic("no hd driver", NOJSÍUM); 
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10055 } 

10056 #endif /* ENABLE_W1N1 */ 


src/kemel/at_wini.c 


10100 /* Este archivo contiene la parte dependiente del dispositivo del controlador 

10101 * en soto para el controlador en har. Winchester de 1BM-AT. 

10102 * Escrita por Adri Koppes. 

10103 * 

10104 * El archivo contiene un punto de entrada: 

10105 * 

10106 * at_winchester_task: entrada princ. al iniciarse el sist. 

10107 * 


10109 

10110 
10111 
10112 

10113 

10114 

10115 

10116 

10117 

10118 

10119 

10120 
10121 
10122 

10123 

10124 

10125 

10126 

10127 

10128 

10129 

10130 

10131 

10132 

10133 

10134 

10135 

10136 

10137 

10138 

10139 

10140 

10141 

10142 

10143 

10144 

10145 

10146 

10147 

10148 

10149 


* Cambios: 

* Abr 13, 1992, por Kees J. Bot: división depend./indep. del dispositivo. 


#include "kemel.h" 
#include "driver.h" 
#include "drvlib.h" 


#if ENABLE_AT_W INI 


/* Puertos de E/S empleados por controladores de disco Winchester. */ 


/* Registros de lectura y escritura */ 


#define REG_B ASEO Ox 1F0 
#defme REG BASE1 0x170 
#defme REG-DATA 0 

#defme REG=PRECOMP 1 

#defme REG COUNT 2 

#defme REG-SECTOR 3 

#defme REG-CYL LO 4 

#defme REG=CYL=H1 5 

#defme REG LDH 6 


#defme LDHDEFAULT 
#defme LDHLBA 
#defme ldh_init(drive) 


/* reg. base de controlador en har. 0 */ 

/* reg. base de controlador en har. 1 */ 

/* reg. datos (distancia del reg. base) */ 

/* inicio de precompensación de escrito */ 

/* sectores por transferir */ 

/* número de sector */ 

/* byte bajo de número de cilindro */ 

/* byte alto de número de cilindro */ 

/* Iba, unidad y cabeza */ 

OxAO /* habilitar ECC 512 bytes/sector */ 
0x40 /* Usar direccionamiento LBA */ 

(LDH DEFAULT I ((drive) « 4)) 


/* Registros sólo de lectura */ 


#defme REG STATUS 7 

#defme STATUS_BSY 
#defme STATUSRDY 
#defme STATUS WF 
#defme STATUS-SC 
#defme STATUS=DRO 
#defíne 
#define 
#defíne 

#defme REG ERROR 
#defme 
#defíne 
#defme 
#defíne 


/* situación */ 

0x80 /* controlador en har. ocupado */ 

0x40 /* unidad lista */ 

0x20 /* falla de escritura */ 

0x10 /* fin de búsqueda (obsoleto) */ 

0x08 /* solicitud transferencia datos */ 

STATUS CRD 
STATUS=1DX 
STATUSERR 
1 

ERRORBB 
ERROR ECC 
ERROR=lD 
ERRORAC 


0x04 /* datos corregidos */ 

0x02 /* pulso índice */ 

0x01 /* error*/ 

/* código de error */ 

0x80 /* bloque malo */ 

0x40 /* bytes ecc malos */ 

0x10 /* no se encontró id */ 

0x04 /* comando abortado */ 
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10150 

10151 

10152 

10153 

10154 

10155 

10156 

10157 

10158 

10159 

10160 
10161 
10162 

10163 

10164 

10165 

10166 

10167 

10168 

10169 

10170 

10171 

10172 

10173 

10174 

10175 

10176 

10177 

10178 

10179 

10180 
10181 
10182 

10184 

10185 

10186 

10187 

10188 

10189 

10190 

10191 

10192 

10193 

10194 

10195 

10196 

10197 

10198 

10199 

10200 
10201 
10202 

10203 

10204 

10205 

10206 

10207 

10208 
10209 


#defme ERRORTK 
#defme ERRORDM 


0x02 /* error de pista cero */ 

0x01 /* no hay marca de dir. de datos */ 


#define 

#define 

#defme 

#define 

#defme 

#define 

#defme 

#define 

#defme 

#define 

#defíne 

#defme 

#define 

#defme 

#define 

#defme 

#define 


sólo de escritura */ 
REGCOMMAND 
CMDIDLE 
CMDRECALIBRATE 
CMDREAD 
CMDWRITE 
CMDREADVERIFY 
CMDFORMAT 
CMDSEEK 
CMDDIAG 
CMDSPECIFY 
ATAIDENTIFY 
REGCTL 0x20 

CTLNORETRY 
CTLNOECC 
CTLEIGHTHEADS 
CTLRESET 
CTLINTDISABLE 


/* para w_command: unidad ociosa ! 
/* recalibrar unidad */ 

/* leer datos */ 

/* escribir datos */ 

/* verificar lectura */ 

/* formatear pista */ 

/* buscar cilindro */ 

/* ejec. diagnóstico de disp. */ 

/* especificar parámetros */ 

/* identificar unidad */ 

'* registro de control */ 

0x80 /* inhábil, reintento de acceso */ 

/* inhábil, reintento de ecc */ 

/* más de 8 cabezas */ 

/* restablecer controlador har. */ 

/* inhabilitar interrupciones */ 


0x10 

0x20 

0x30 

0x40 

0x50 

0x70 

0x90 

0x91 

OxEC 


0x40 

0x08 

0x04 

0x02 


/* Líneas de solicitud de interrupción. */ 

#define AT_IRQ0 14 /* núm. interrupción p/controlador 0 */ 

#define AT IRQl 15 /* núm. interrupción p/controlador 1 */ 


/* Bloque de comando común */ 
struct command { 

u8_t precomp;/* REG PRECOMP, etc. */ 
u8_t count; 
u8_t sector; 
u8_t cyl_lo; 

u8_t cyl_hi; 10183 u8_t ldh; 
u8_t command; 


/* Códigos de error */ 

#define ERR (-1) /* error general */ 

#define ERR BAD SECTOR (-2) /* detección de bloque marcado malo */ 


/* Algunos contr. en har. no interrumpen, el reloj nos despertará. */ 
#define WAKEUP (32*HZ) /* unidad apagada 31 seg. máximo */ 


/* Diversos. */ 

#define MAXDRIVES 
#if WORD SIZE > 2 
#define MAX_SECS 
#else 

#define MAX_SECS 
#endif 


4 /* este contr. apoya 4 unidades (hd0-hdl9) */ 

256 /* contr. har. puede transí este # sectores */ 

127 /* pero no a un proceso de 16 bits */ 


#define MAX_ERRORS 4 /* cuánto intentar rd/wt antes de desistir */ 

#define NR_DEVICES (MAX DRIVES * DEV PER DRIVE) 

#define SUB PER DRIVE (NR_PARTITIONS * NR PARTITIONS) 

#define NR_SUBDEVS (MAX DRIVES * SUB PER DRIVE) 

#define TIMEOUT 32000 /* plazo de contr. en har. en ms */ 

#define RECOVERYTIME 500 /* tiempo recup. contr. har. en ms */ 

#define INITIALIZED 0x01 /* unidad inicializada */ 

#define DEAF 0x02 /* contr. har. debe restablecerse */ 
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10210 #define SMART 0x04 /* unidad reconoce comandos ATA */ 

10211 
10212 

10213 /* Variables. */ 

10214 PRIVATE struct wini { /* struct de unidad princ, 1 entrada/unidad */ 

10215 unsigned State; /* estado unidad: sorda, iniciada, muerta */ 

10216 unsigned base; /* reg. base del archivo de registros */ 

10217 unsigned irq; /* línea de solicitud de interrupción */ 

10218 unsigned lcylinders; /* núm. lógico de cilindros (BIOS) */ 

10219 unsigned lheads; /* núm. lógico de cabezas */ 

10220 unsigned lsectors; /* núm. lógico de sectores/pista */ 

10221 unsigned pcylinders; /* núm. fís. de cilindros (traducido) */ 

10222 unsigned pheads; /* núm. fís. de cabezas */ 

10223 unsigned psectors; /* núm. fís. de sectores/pista */ 

10224 unsigned ldhpref; /* 4 bytes altos del reg. LDH (cabeza) */ 

10225 unsigned precomp; /* cil. precompens. escritura /4*/ 

10226 unsigned max_count; /* máx. solicitudes p/esta unidad */ 

10227 unsigned open_ct; /* cuenta en uso */ 

10228 struct device part[DEV_PER_DRIVE]; /* partic. primarias: hd[0-4] */ 

10229 struct device subpart[SUB_PER_DRIVE]; /* subparticiones: hd[l-4][a-d] */ 

10230 } wini[MAX_DRIVES], *w_wn; 

10231 

10232 PRIVATE struct trans { 

10233 struct iorequest_s *iopj /* pertenece a esta solicitud de E/S */ 

10234 unsigned long block; /* primer sector por transferir */ 

10235 unsj-gned count; /* cuenta de bytes */ 

10236 phys_bytes phys; /* dirección física del usuario */ 

10237 } wtranS[NR_IOREQS); 

10238 

10239 PRIVATE struct trans *W_tp; /* p/agregar solicitudes de transí. */ 

10240 PRIVATE unsigned w_count; /* núm. bytes por transferir */ 

10241 PRIVATE unsigned long w_nextblock; /* sigo bloque disco por transferir */ 

10242 PRIVATE int w_opcode; /* DEV READ o DEV WRITE */ 

10243 PRIVATE int w_command; /* comando en ejecución actual */ 

10244 PRIVATE int w_status; /* situac. después de interrupción */ 

10245 PRIVATE int w_drive; /* unidad seleccionada */ 

10246 PRIVATE struct device *w_dv; /* base y tamaño de dispositivo */ 

10247 

10248 FORWARD _PROTOTYPE( void init_params, (void)); 

10249 FORWARD _PROTOTYPE( int w do open, (struct driver *dp, message *m_ptr)); 

10250 FORWARD _PROTOTYPE( struct device *w_prepare, (int device)); 

10251 FORWARD _PROTOTYPE( int w_identify, (void)); 

10252 FORWARD _PROTOTYPE( char *w_name, (void)); 

10253 FORWARD _PROTOTYPE( int w_specify, (void)); 

10254 FORWARD _PROTOTYPE( int w_schedule, (int proc_nr, struct iorequest_s *iop) ); 

10255 FORWARD _PROTOTYPE( int wjinish, (void)); 

10256 FORWARD _PROTOTYPE( int com out, (struct command *cmd)); 

10257 FORWARD _PROTOTYPE( void w_need_reset, (void)); 

10258 FORWARD _PROTOTYPE( int w do close, (struct driver *dp, message *m_ptr)); 

10259 FORWARD _PROTOTYPE( int com simple, (struct command *cmd)); 

10260 FORWARD _PROTOTYPE( void w_timeout, (void) ); 

10261 FORWARD _PROTOTYPE( int w_reset, (void)); 

10262 FORWARD _PROTOTYPE( int w_intr_wait, (void) ); 

10263 FORWARD _PROTOTYPE( int w_waitfor, (int mask, int valué) )j 

10264 FORWARD _PROTOTYPE( int w_handler, (int irq)); 

10265 FORWARD _PROTOTYPE( void w geometry, (struct partition *entry)); 

10266 

10267 /* ciclo w_waitfor desenrollado una vez para agilizar. */ 

10268 #defme waitfor(mask, valué) \ 

10269 ((in_byte(w_wn->base + REG STATUS) & mask) = valué \ 
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10270 | | w_waitTor(mask, valué)) 

10271 

10272 

10273 /* Entrada apunta a este controlador en software. */ 

10274 PRIVATE struct driver w_dtab = { 

10275 w_name, /* nombre del dispositivo actual */ 

10276 w_do_open, /* solic. abrir o montar, inicializar disp. */ 

10277 w_do_close, /* liberar dispositivo */ 

10278 do_diocntl, /* obtener o fijar geom. de 1 partición */ 

10279 w_prepare, /* preparar para E/S en disp. seco dado */ 

10280 w_schedule, /* precalcular cil., cabeza, sector, etc. */ 

10281 w_finish; /* efectuar E/S */ 

10282 nop_cleanup, /* nada que asear */ 

10283 w_geometry, /* indicar geometría del disco */ 

10284 }; 

10285 

10286#if ENABLEATAPI 

10287 #include "atapi.c" /* código extra p/ATAPI CD-ROM */ 

10288 #endif 

10289 

10290 

10291 /♦==== ===== ==== == = ==== === = == == = = === = = === = 

10292 * at_winchester_task * 

10293 *============ == ==== = == == = = = === == ========== 

10294 PUBLIC void at_winchester_task() 

10295 { 

10296 /* Fijar paráms. especiales de disco e invocar ciclo principal genérico. */ 

10297 

10298 init_params(); 

10299 

10300 driver_task(&w_dtab); 

10301 } 

10304 /♦============================== = ============================ == = 

10305 * init_params * 

10306 *=== . === =.= ====== = =====: . == ==== ======== = ====== ===== =============== 

10307 PRIVATE void init_params() 

10308 { 

10309 /* Esta rutina se llama al arrancar p/inicializar paráms. de la unidad. */ 

10310 

10311 ul6_t parv[2]; 

10312 unsigned int vector; 

10313 int drive, nr_drives, i; 

10314 struct wini *wn; 

10315 u8_t params [16]; 

10316 phys_bytes param~phys = vir2phys(params); 

10317 

10318 /* Obtener núm. de unidades del área de datos de BIOS. */ 

10319 phys_coPy(0x475L, param_phys, 1L); 

10320 if ((nr_drives = params[0]) > 2) nr_drives = 2; 

10321 

10322 for (drive = 0, wn = wini; drive < MAX_DRTVES; drive++, wn++) { 

10323 if (drive < nr_drives) { 

10324 /* Copiar el vector de parámetros de BIOS */ 

10325 vector = drive = 0 ? WINI_0_PARM_VEC : WINI_1_PARM_VEC; 

10326 phys_copy(vector * 4L, vir2phys(parv), 4L); 

10327 

10328 /* Calcular dirección de los paráms. y copiarlos */ 

10329 phys_copy(hclick_to_Physb(parv[l]) + parv[0], param_phys, 16L); 
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10330 

10331 

10332 

10333 

10334 

10335 

10336 

10337 

10338 

10339 

10340 

10341 

10342 

10343 

10344 

10345 

10346 

10347 

10348 

10349 

10352, 

10353 * w_do_open 

10354 * = = == ======= = = == = = = = = == == = = == = = = = == 

10355 PRIVATE int w_do_open(dp, m_ptr) 

10356 struct driver *dp; 

10357 message *m_ptr; 

10358 { 

10359 /* Abrir dispositivo: Inic. controlador har. y leer tabla partic. */ 

10360 

10361 int r; 

10362 struct wini *wn; 

10363 struct command cmd; 

10364 

10365 if (w_prepare(m_ptr.>DEVICE) —NIL DEV) retum(ENXIO); 

10366 wn = w_wn; 

10367 

10368 if (wn.>state == 0) { 

10369 /* Tratar de identificar el dispositivo. */ 

10370 if (w_identify() != OK) { 

10371 printf("%s: probe failed\n", w_name()); 

10372 if (wn->state & DEAF) w_reset(); 

10373 wn->state = 0; 

10374 retum(ENXIO); 

10375 } 

10376 } 

10377 if (wn->open_ct++= 0) { 

10378 /* Dividir el disco en particiones. */ 

10379 partition(&w_dtab, w_drive * DEV PER DRIVE, P PRIMARY); 

10380 } 

10381 retum(OK); 

10382 } 

10385 /♦==—===== = = = —===== == = ===== ====== 

103 86 * w_prepare 

10387 *============ ==== === ========== == 

10388 PRIVATE struct device *w_prepare(device) 

10389 int device; 


/* Copiar paráms. en estructuras de la unidad */ 
wn.>lcylinders = bp_cylinders(params); 
wn.>lheads = bp_heads(params); 
wn->lsectors = bp_sectors(params); 
wn->precomp = bp_precomp(params) » 2; 

} 

wn.>ldhpref = ldh_init(drive)j 

wn.>max_count = MAX SECS «SECTOR_SHIFT; 

if (drive < 2) { 

/* Controller 0. */ 
wn->base = REGBASE0; 
wn.>irq = ATIRQ0; 

} else { 

/* Controller 1. */ 
wn->base = REGBASEl; 
wn.>irq = ATIRQl; 
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10390 { 

10391 /* Preparar para E/S en un dispositivo. */ 

10392 

10393 /* Nada que transferir aún. */ 

10394 w_count = Oj 

10395 

10396. if (device < NR_DEVICES) { /* hdO, hdl, ...*/ 

10397 w drive = device / DEVPERDRIVE; /* guardar núm. de unidad */ 

10398 w_wn = &wini[w_drive]; 

10399 w_dv = &w_wn->part[device % DEV PER DRIVE]; 

10400 } else 

10401 if «unsigned) (device -= MINORJidla) <NR_SUBDEVS) { /* hdla, hdlb, ...*/ 

10402 w_drive = device / SUBPERDRTVE; 

10403 w_wn = &wini [w_drive]; 

10404 w_dv = &w_wn->subpart [device % SUBPERDRTVE]; 

10405 } else { 

10406 retum(NIL_DEV); 

10407 } 

10408 retum(w_dv); 

10409 } 

10412 /*====== = = == = = ======== = = = == = ====== = ======== = = == === = == == == = = = =* 

10413 * w_identify * 

10414 *== == = = === = = = == == = === = = = = = ===== = = = == == == = === == = = = = == = = = = = = */ 

10415 PRIVATE int w_identify() 

10416 { 

10417 /* Averiguar si existe dispositivo, si es un disco AT viejo o una unidad ATA 

10418 * más nueva, un dispositivo de medio removible, etc. 

10419 */ 

10420 

10421 struct wini *wn = w_wn; 

10422 struct command cmd; 

10423 char id_string[40]; 

10424 int i, r; 

10425 unsigned long size; 


10426 


#defme id_byte(n) 


(&tmp buf[2 

10427 


#define id word(n) 


(((ul 6_t) id_byte(n)[0]« 0) \ 

10428 


|((ul6_t) id_byte(n)[l]« 

8)) 


10429 


#define id longword(n) 


(((u32_t) id_byte(n)[0)« 0) \ 

10430 


|( (u32_t) id_byte(n)[l]« 

8) \ 


10431 


|((u32 t) id byte(n)[2] « 

16) \ 


10432 


|((u32_t) id_byte(n)[3]« 

24)) 


10433 

10434 / 

'* Verificar si existe 

uno de los registros. */ 



10435 i 

• = in_byte(wn->base 

: + REG CYL LO); 



10436 ( 

)ut_byte(wn->base + 

REG CYL LO, -r); 




10437 if (in_byte(wn->base + REGCYLLO) == r) retum(ERR); 

10438 

10439 /* Parece correctoj registrar IRQ e intentar comando de identificación ATA. */ 

10440 put_irq_handler(wn->irq, w_handler); 

10441 enable_irq(wn->irq); 

10442 

10443 cmd.ldh = wn->ldhpref; 

10444 cmd.command = ATAIDENTIFY; 

10445 if (com_simple(&cmd) = OK) { 

10446 /* Es un dispositivo ATA. */ 

10447 wn->state 1 = SMART; 

10448 

10449 /* Información del dispositivo. */ 
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10450 port_read(wn->base + REGDATA, tmp_phys, SECTORSIZE); 

10451 

10452 /* ¿Por qué están intercambiados bytes de la cadena? */ 

10453 for (i = 0; i < 40; i++) id_string[i] = id_byte(27)[i A l]; 

10454 

10455 /* Modo de traducción CHS preferido. */ 

10456 wn->pcylinders = id_word(l); 

10457 wn->pheads = id_word(3); 

10458 wn->psectors = id_word(6); 

10459 size = (u32_t) wn->pcylinders * wn->pheads * wn->psectors; 

10460 

10461 if ((id_byte(49)[l] & 0x02) && size > 512L*1024*2) { 

10462 /* La unidad tiene capacidad LBA y tamaño suficiente para confiar 

10463 * en que no causará un desastre. 

10464 */ 

10465 wn->ldhpref 1 = LDHLBA; 

10466 size = id_Iongword(60); 

10467 } 

10468 

10469 if (wn->lcylinders = 0) { 

10470 /* ¿No hay parámetros BIOS? Inventarlos. */ 

10471 wn->lcylinders = wn->pcylinders; 

10472 wn->lheads = wn->pheads; 

10473 wn->lsectors = wn->psectors; 

10474 while (wn->lcylinders > 1024) { 

10475 wn->lheads *= 2; 

10476 wn->lcylinders /= 2; 

10477 } 

10478 } 

10479 } else { 

10480 /* No es dispositivo ATAj no traducciones, no funciones especiales. 

10481 * No tocarlo a menos que BIOS esté enterado. 

10482 */ 

10483 if (wn->lcylinders = 0) retum(ERR); /* no hay paráms. BIOS */ 

10484 wn->pcylinders = wn->lcylinders; 

10485 wn->pheads = wn->lheads; 

10486 wn->psectors = wn->lsectors; 

10487 size = (u32_t) wn->pcylinders * wn->pheads * wn.>psectors; 

10488 } 

10489 /* La diversión termina en 4 GB. */ 

10490 if (size > ((u32_t) -1); SECTOR_SIZE) size = ((u32_t) -1); SECTOR_SIZE; 

10491 

10492 /* Base y tamaño de toda la unidad. */ 

10493 wn->part[0] ,dv_base = 0; 

10494 wn->part[0] ,dv_size = size « SECTOR_SHIFT; 

10495 

10496 if (w_specify() 1= OK && w_specify() != OK) retum(ERR); 

10497 

10498 printf("%s:", w_name()); 

10499 if (wn->state & SMART) { 

10500 printf("%.40s\n", id_string); 

10501 } else { 

10502 printf("%ux%ux%u\n", wn->pcylinders, wn->pheads, wn->psectors); 

10503 } 

10504 retum(OK); 

10505 } 


10508 /*= 
10509* 
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10510 * = = == = = ===== = = = === = = = = == = = = = = = = ===== = = = = = = = == = ==== == == = == = = = = = = */ 

10511 PRIVATE char * w_name( ) 

10512 { 

10513 /* Devolver un nombre para el dispositivo actual. */ 

10514 static char name[ ] = "at-hdl5"; 

10515 unsigned device = w drive * DEV PER DRIVE; 

10516. 

10517 if (device < 10) { 

10518 name[5] = ’0' + device; 

10519 ñame [6] = 0; 

10520 } else { 

10521 name[5] = '0' + device / 10; 

10522 name[6] = ’0' + device % 10; 

10523 } 

10524 retumname; 

10525 } 

10528 /♦====================== === ================ === ==============♦ 

10529 * w_specify * 

10530 *============================= == =============== == ==============*/ 

10531 PRIVATE int w_specify() 

10532 { 

10533 /* Inicializar unidad después del arranque o si es necesario restablecerla. */ 

10534 

10535 struct wini *wn = w_wn; 

10536 struct command cmd; 

10537 

10538 if ((wn->state & DEAF) && w_reset() != OK) retum(ERR); 

10539 

10540 /* Especificar paráms.: precompensación, núm. cabezas y sectores. */ 

10541 cmd.precomp = wn->precomp; 

10542 cmd.count = wn->psectors; 

10543 cmd.ldh = w_wn->ldhpref 1 (wn->pheads-1); 

10544 cmd.command = CMD SPECIFY; /* Especificar algunos paráms. */ 

10545 

10546 if (com_simple(&cmd) != OK) retum(ERR); 

10547 

10548 if (! (wn->state & SMART)) { 

10549 /* Calibrar un disco viejo. */ 

10550 cmd.sector = Oj 

10551 cmd.cyl_lo = Oj 

10552 cmd.cyl_hi = 0; 

10553 cmd.ldh = w_wn->ldhpref; 

10554 cmd.command = CMDRECALIBRATE; 

10555 

10556 if (com_simple(&cmd) != OK) retum(ERR); 

10557 } 

10558 

10559 wn->state 1= INITIALIZED; 

10560 retum(OK); 

10561 } 

10564 /*=== = = = = = ====== = = = = = === = = = == = === = == = === = == = = = = === = = = === ======* i 

10565 * w schedule *r 

10566 * —.■■ ==== = ========= = =-=================================♦/ 

10567 PRIVATE int w_schedule(proc_nr, iop) 

10568 int proc_nr; /* proceso que solicita */ 

10569 struct iorequest_s *iop; /* apunto a solic. de leer o escribir */ 
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10570 { 

10571 /* Reunir solicitudes de E/S en bloques consecutivos para poder leer/escribir 

10572 * en un solo comando. (Hay suficiente tiempo para calcular la sigo solicitud 

10573 * consecutiva mientras pasa un bloque no deseado.) 

10574 */ 

10575 struct wini *wn = w_wn; 

10576 int opcode; 

10577 unsigned long pos; 

10578 unsigned nbytes, count; 

10579 unsigned long block; 

10580 phys_bytes user_phys; 

10581 

10582 /* Este número de bytes por leer/escribir */ 

10583 nbytes = iop->io_nbytes; 

10584 if ((nbytes & SECTORMASK) != 0) retum(iop->io_nbytes = EINVAL); 

10585 

10586 /* De/a esta posición en el dispositivo */ 

10587 pos = iop->io_position; 

10588 if ((pos & SECTOR MASK) != 0) retum(iop->io_nbytes = EINVAL); 

10589 

10590 /* De/a esta dir~cción de usuario */ 

10591 user_phys = numap(proc_nr, (vir_bytes) iop->io_buf, nbytes); 

10592 if (user_phys = 0) retum(iop->io_nbytes = EINVAL); 

10593 

10594 /* ¿Leer o escribir? */ 

10595 opcode = iop->io_request & -OPTIONAL IO; 

10596 

10597 /* ¿Cuál bloque en disco y qué tan cerca de EOF? */ 

10598 if (pos >= w_dv->dv_size) retum(OK); /* At EOF */ 

10599 if (pos + nbytes > w_dv->dv_size) nbytes = w_dv->dv size -pos; 

10600 block = (w_dv->dv_base + pos) » SECTOR_SHIFT; 

10601 

10602 if (w_count > 0 && block != w_nextblock) { 

10603 /* Esta nueva solicitud no puede encadenarse al trabajo */ 

10604 if ((r = w_finish()) != OK) retum(r); 

10605 } 

10606 


10607 /* El siguiente bloque consecutivo */ 

10608 w_nextblock = block + (nbytes » SECTOR_SHIFT); 

10609 


10610 /* Mientras haya bytes "no planificados" en la solicitud: */ 


10611 do { 

10612 

10613 

10614 

10615 

10616 

10617 

10618 

10619 

10620 
10621 
10622 

10623 

10624 

10625 

10626 

10627 

10628 
10629 


count = nbytes; 

if (w_count = wn->max count) { 

/* La unidad no puede hacer más que max_count a la 
if ((r = w_finish()) != OK) retum(r); 

} 


if (w_count + count > wn->max_count) 

count = wn->max_count -w_count; 

if (w_count = 0) { 

/* La primera solicitud de una fila, inicializar. */ 
w_opcode = opcode; 
w_tp = wtrans; 


/* Guardar parámetros de E/S */ 
w_tp->iop = iop; 


*/ 
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10630 w_tp->block = block; 

10631 w_tp->count = count; 

10632 w_tp->phys = user_phys; 

10633 

10634 /* Update counters */ 

10635 w_tp++; 

10636. w_count += count; 

10637 block+= count» SECTOR_SHIFT; 

10638 user_phys += count; 

10639 nbytes -= count; 

10640 } while (nbytes > 0); 

10641 

10642 retum(OK); 

10643 } 


10646 / 

10647 

10648 ! 

10649 

10650 

10651 

10652 

10653 

10654 

10655 

10656 

10657 

10658 

10659 

10660 
10661 
10662 

10663 

10664 

10665 

10666 

10667 

10668 

10669 

10670 

10671 

10672 

10673 

10674 

10675 

10676 

10677 

10678 

10679 

10680 
10681 
10682 

10683 

10684 

10685 

10686 

10687 

10688 
10689 


PRIVATE int w_finish() 

{ 

/* Ejecutar solicitudes de E/S reunidas en wtransj], * 


struct command cmd; 

unsigned cylinder, head, sector, secspcyl; 

if (w_count = 0) return(OK); /* Finalización espuria. */ 

/* Disparar el primer com_out */ 


r = ERR; 
errors = 0; 


if (r != OK) { 

/* El controlador en har. debe (re)programarse. */ 

/* Primero ver si es preciso reinicializar. */ 
if (1 (wn->state & INITIALIZED) && w_specify() != OK) 
retum(tp->iop->io_nbytes = EIO); 

/* Decir al controlador en har. que transfiera w_count bytes */ 
cmd.precomp = wn->precomp; 

cmd.count = (w_count » SECTOR_SHIFT) & BYTE; 
if (wn->ldhpref & LDH LBA) { 

cmd.sector = (tp->block» 0) & OxFF; 

cmd.cyl lo =(tp->block» 8) & OxFF; 

cmd.cyl_hi = (tp->block» 16) & OxFF; 

cmd.ldh = wn->ldhpref I «(tp->block » 


} else { 


secspcyl = wn->pheads * wn->psectors; 
cylinder = tp->block / secspcyl; 
head = (tp->block % secspcyl) / wn->psectors; 
sector = tp->block % wn->psectors; 
cmd.sector = sector + 1; 

cmd.cyl_lo = cylinder & BYTE; 

cmd.cyl_hi = (cylinder» 8) & BYTE; 

cmd.ldh = wn->ldhpref I head; 
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10690 

cmri.commanri = w opcode = DEV WRITE ? CMD WRITE : CMD READ; 

10691 



10692 

if((r = 

com out(&cmd)) != OK) { 

10693 


if (++errors == MAXERRORS) { 

10694 


wcommand = CMDIDLE; 

10695 


retum(tp->iop->io nbytes = EIO); 

10696 


} 

10697 


continué; /* Retry */ 

10698 

} 


10699 

} 


10700 



10701 

/* Para cada sector, esperar interrupción y traer datos (read) 

10702 

* o enviar d 

atos al contr. har. y esperar interrupción (write). 

10703 

*/ 


10704 



10705 

if (w opcode = 

DEV READ) { 

10706 

if(( = 

w_intr_wait()) = OK) { 

10707 


/* Copiar datos del buffer del disp. al espacio de usuario. */ 

10708 



10709 


port_read(wn->base + REGDATA, tp->phys, SECTORSIZE); 

10710 



10711 


tp->phys += SECTORSIZE; 

10712 


tp->iop->io_nbytes -= SECTOR SIZE; 

10713 


w count -= SECTOR SIZE; 

10714 


if ((tp->count -= SECTOR SIZE) = 0) tp++; 

10715 

} else 

{ 

10716 


/* ¿Hay datos defectuosos? */ 

10717 


if (w status & STATUS DRQ) { 

10718 


port read(wn->base + REG DATA, tmp_phys, 

10719 


SECTOR SIZE); 10720 

10721 


} 

10722 

} else { 


10723 

/* Espi 

erar datos solicitados. */ 

10724 

if (!waitfor(STATUS_DRQ, STATUSDRQ)) { 

10725 


r = ERR; 

10726 

} else 

{ 

10727 


/* Llenar el buffer de la unidad. */ 

10728 



10729 


port_write(wn->base + REG DATA, tp->phys, SECTOR SIZE); 

10730 


r = w intr wait(); 

10731 

} 


10732 



10733 

if ( r== 

OK) { 

10734 


/* Reservar bytes escritos con éxito. */ 

10735 



10736 


tp->phys + = SECTORSIZE; 

10737 


tp->iop->io nbytes - = SECTOR SIZE; 

10738 


w count -= SECTOR SIZE; 

10739 


if ((tp->count -= SECTORSIZE) = 0) tp++; 

10740 

} 


10741 

} 


10742 



10743 

if (r != OK) { 


10744 

/* No reintentar si sector marcado malo o demasiados errores. */ 

10745 

if(r = 

^ ERR BAD SECTOR | | ++errors == MAX ERRORS) { 

10746 


wcommand = CMDIDLE; 

10747 


retum(tp->iop->io_nbytes = EIO); 

10748 

} 


10749 
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10750 /* Restablecer si a la mitad, pero abandonar si EfS opcional. */ 

10751 if (errors = MAXERRORS / 2) { 

10752 w_need_reset(); 

10753 if (tp->iop->io_request & OPTIONAL IO) { 


10754 

10755 

10756 

10757 } 

10758 continué; 

10759 } 

10760 errors = 0; 

10761 } while (w_count > 0); 

10762 

10763 wcommand = CMDIDLE; 

10764 retum(OK); 

10765 } 


wcommand = CMDIDLE; 
retum(tp->iop->io_nbytes = EIO); 

/* Reintentar */ 


10768/*================================================================* 

10769 * comout * 

10770 *============================= == =============== == ===============*/ 

10771 PRIVATE int comout(cmd) 

10772 struct command *cmd; /* Bloque de comando */ 

10773 { 

10774 /* Enviar bloque de comando a contr. har. Winchester y devolver situación */ 

10775 

10776 struct wini *wn = w_wn; 

10777 unsigned base = wn->base; 

10778 

10779 if (!waitfor(STATUS_BSY, 0)) { 

10780 printf("%s: controller not ready\n", w_name()); 

10781 retum(ERR); 

10782 } 

10783 

10784 /* Escoger unidad. */ 

10785 out_byte(base + REG LDH, cmd->ldh); 

10786 

10787 if (!waitfor(STATUS_BSY, 0)) { 

10788 printf("%s: drive not ready\n", w_name()); 

10789 return(ERR); 

10790 } 

10791 

10792 /* Planificar llamada pfdespertar, algunos controladores no confiables. */ 

10793 clock_mess(WAKEUP, w timeout); 

10794 

10795 out_byte(base + REG CTL, wn->pheads >= 8 ? CTL EIGHTHEADS : 0); 

10796 out_byte(base + REG PRECOMP, cmd->precomp); 

10797 out_byte(base + REG COUNT, cmd->count); 

10798 out_byte(base + REG SECTOR, cmd->sector); 

10799 out_byte(base + REG CYL LO, cmd->cyl_lo); 

10800 out_byte(base + REG CYL HI, cmd->cyl_hi); 

10801 lock(); 

10802 out_byte(base + REG COMMAND, cmd->command); 

10803 w command = cmd->command; 

10804 w_status = STATUS_BSY; 

10805 unlock(); 

10806 retum(OK); 


} 
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10810 /*==== ====== = = = ====== 

10811 * w_need_reset 

10812 * = = == = = ======== = === = = = = ==== = == == === === 

10813 PRIVATE void w_need_reset() 

10814 { 

10815/* Hay que restablecer el controlador en hardware. */ 

10816 struct wini *wn; 

10817 

10818 for (wn = wini; wn < &wini[MAX_DRIVES]; wn++) { 

10819 wn->state 1 = DEAF; 

10820 wn->state &= -INITIALIZED; 

10821 } 

10822 } 

10825 

10826 

10827 

10828 

10829 

10830 

10831 

10832 

10833 

10834 

10835 

10836 

10837 

10840 /*======================= = ================ = ===============: 

10841* com_simple 

10842 *== = = = ===== = = = ======= = == = ===== = === = == = ====== = = = = = == === 

10843 PRIVATE int comsimple(cmd) 

10844 struct command *cmd; /* Bloque de comando. */ 

10845 { 

10846 /* Comando de controlador simple, sólo 1 int. sin fase de sacar datos. */ 

10847 int r; 

10848 

10849 if ((r = com out(cmd)) = OK) r = w_intr_wait(); 

10850 w command = CMD IDLE; 

10851 retum(r); 

10852 } 

10855 /*================== === ====================== == ==== = 

10856* w_timeout 

10857 *============ = ================= = ===================== == 

10858 PRIVATE void w_timeout() 

10859 { 

10860 struct wini *wn = w_wn; 

10861 

10862 switch (w_command) { 

10863 case CMD IDLE: 

10864 break; /* perfecto */ 

10865 case CMD READ: 

10866 case CMD WRITE: 

10867 /* Imposible, pero no en PC: El controlador en har. no responde. */ 

10868 

10869 /* Limitar la E/S multisector parece ayudar. */ 


w_do_close 


PRIVATE int w_do_close(dp, m_ptr) 
struct driver *dp; 
message *m_ptr; 

/* Cerrar dispositivo: Liberar un dispositivo. */ 
if (w_prepare(m_ptr->DEVICE) = NIL DEV) retum(ENXIO); 
retum(OK); 
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10870 if (wn->max_count > 8 * SECTOR_SIZE) { 

10871 wn->max_count = 8 * SECTOR_SIZE; 

10872 } else { 

10873 wn->max_count = SECTORSIZEj 

10874 } 

10875 /*CONTINUAR CON LA SIGUIENTE RUTINA*/ 

10876 default: 

10877 /* Algún otro comando. */ 

10878 printf("%s: timeout on command %02x\n", w_name(), w_command); 

10879 w_need_reset(); 

10880 w_status = 0; 

10881 interrupt(WINCHESTER); 

10882 } 

10883 } 


10886 /*==========================;====================== = === == * 

10887 * w_reset * 

10888 *======= = =============== = ========================= == =============*/ 

10889 PRIVATE int w_reset() 

10890 { 

10891 /* Enviar un reset al controlador en hardware. Esto se hace después 

10892 * de cualquier catástrofe, como cuando el controlador no responde. 

10893 */ 

10894 

10895 struct wini *wn; 

10896 int err; 

10897 

10898 /* Esperar recuperación interna de la unidad. */ 

10899 millidelay(RECOVERYTIME); 

10900 

10901 /* Bit de restablecimiento estroboscópico */ 

10902 out_byte(w_wn->base + REGCTL, CTL RESET); 

10903 milli_delay(l); 

10904 out_byte(w_wn->base + REG CTL, 0); 

10905 milli_delay(l); 

10906 

10907 /* Esperar a que el controlador esté listo */ 

10908 if (!w_waitfor(STATUS_BSY I STATUSRDY, STATUSRDY)) { 

10909 printf("%s: reset failed, drive busy\n", w_name()); 

10910 return(ERR); 

10911 } 

10912 

10913 /* El reg. de error debe revisarse aquí, pero algunas unidades se equivocan. */ 

10914 

10915 for (wn = wini; wn < &wini[MAX_DRIVES]; wn++) { 

10916 if (wn->base == w_wn->base) wn->state &= -DEAF; 

10917 } 

10918 retum(OK); 

10919 } 

10922 /*= = = = = === = = = = = = === = = = = = === = = = = = = == = = === = = == = = == == = ==== = === * 

10923 * w_intr_wait * 

10924*================================================================*/ 

10925 PRIVATE int w_intr_wait() 

10926 { 

10927 /* Esperar que una tarea termine interrupción y devuelva resultados. */ 

10928 

10929 message mess; 
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10930 intr; 

10931 

10932 /* Esperar interrupción que inicie w_status para "no ocupado". */ 

10933 while (w_status & STATUS_BSY) receive (HARDWARE , &mess; 

10934 

10935 /* Verificar situación. */ 

10936 lock(); 

10937 if ((w_status & (STATUS_BSY | STATUSRDY | STATUS_WF | STATUSERR)) 

10938 = STATUS RDY) { 

10939 r = OK; 

10940 w_status |= STATUS_BSY; /* suponer aún ocupada con E/S */ 

10941 } else 

10942 if ((w_status & STATUS ERR) && (in_byte(w_wn->base + REG ERROR) & ERROR BB)) { 

10943 r = ERR BAD SECTOR; /* sector malo, inútil reintentar */ 

10944 } else { 

10945 r = ERR; /* cualquier otro error */ 

10946 } 

10947 unlock(); 

10948 retum(r); 

10949 } 

10952/*========================================================== 

10953* w_waitfor * 

10954 *========================================================== 

10955 PRIVATE int w_waitfor(mask, valué) 

10956 int mask; /* máscara de situación */ 

10957 int valué; /* situación requerida */ 

10958 { 

10959 /* Esperar que controlador esté en estado requerido. Devolver 0 al vencer plazo. */ 

10960 

10961 struct milli_state ms; 

10962 

10963 milli_start(&ms); 

10964 do { 

10965 if «in_byte(w_wn->base + REG STATUS) & mask) = valué) retum 1; 

10966 } while (milli_elapsed(&ms) < TIMEOUT); 

10967 

10968 w_need_reset(); /* El controlador en hardware está sordo. */ 

10969 retum(O); 

10970 } 

10973 /*========================================================== 

10974* w_handler * 

10975 *=============================================-============ 

10976 PRIVATE int w_handler(irq) 

10977 int irq; 

10978 { 

10979 /* Interrupción de disco, enviar mens. a tarea winch. y rehabil. ints. */ 

10980 

10981 w_status = in_byte(w_wn->base + REG_STATUS); 1 * acusar interrupción *1 

10982 interrupt(WINCHESTER); 

10983 retum 1; 

10984 } 


10987 /* 
10988* 
10989 *= 


v_geometry 
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10990 PRIVATE void w geometry(entry) 

10991 struct partition *entry; 

10992 { 

10993 entry->cylinders = w_wn->lcylinders; 

10994 entry->heads = w_wn->lheads; 

10995 entry->sectors = w_wn->lsectors; 

10996 } 

10997 #endif /* ENABLE AT WINI */ 


src/kemel/clock.c 


11000 /* Este archivo contiene el código y datos para la tarea del reloj. Esta tarea 

11001 * acepta seis tipos de mensajes: 

11002 * 

11003 * HARD_INT: ocurrió una interrupción de reloj 

11004 * GET UPTIME: obtener tiempo en tics desde el arranque 

11005 * GET-TIME: un proceso quiere el tiempo real en segundos 

11006 * SET-TIME: un proc. quiere fijar el tiempo real en segundos 

11007 * SET-ALARM: un proc. quiere que le avisen después de cierto intervalo 

11008 * SET:=SYN_AL: fijar la alarma síncrona 

11009 * 

11010 * 

11011 * El mensaje de entrada es formato m6. Los parámetros son: 

11012 * 

11013 * m type CLOCK PROC FUNC NEW_TIME 

11014 * 

11015 * 

11016 * 

11017 * 

11018 * 

11019 * 

11020 * 

11021 * 

11022 * 

11023 * 

11024 * 

11025 * 

11026 * 

11027 * NEW_TIME, DELTA CLICKS y SECONDS LEFT se refieren 

11028 * al mismo campo del mensaje, dependiendo del tipo de mensaje. 

11029 * 

11030 * Los mensajes de respuesta son de tipo OK, excepto en caso de HARDINT, 

11031 * al cual no se responde. Para los mensajes GET_* se devuelve el tiempo 

11032 * en el campo NEW TIME, y para SETALARM y SET SYN ALARM 

11033 * se devuelve en ese campo el tiempo en segundos que falta para que se devuelva 

11034 * la alarma. 

11035 * 

11036 * Al sonar una alarma, si el invocador es un proc. de usuario, se le envia 

11037 * una señal SIGALRM. Si es una tarea, se invocará una fuñe, especificada 

11038 * por el invocador, la cual podría, p.ej., enviar un mensaje, pero 

11039 * sólo si está segura de que la tarea estará bloqueada cuando el temporiz. 

11040 * llegue a 0. Una alarma síncrona envía un mens. a la tarea de alarma 

11041 * síncrona, que a su vez puede enviar un mens. a otro servidor. Esta es la única 

11042 * forma de enviar una alarma a un servidor, pues los servidores no pueden 

11043 * usar el meco de llamar fuñe, que usan las tareas y no pueden recibir señales. 

11044 */ 


f a llam. | delta 


|GET_UPTIME | 


SET ALARM | proc_n 


SET_SYN_AL | proc_nr 
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11045 

11046 #include "kemel.h" 

11047 #include <signal.h> 

11048 #include <minix/callnr.h> 

11049 #include <minix/com.h> 

11050 #include "proc.h" 

11051 

11052 /* Definiciones de constantes. */ 

11053 #define MILLISEC 100 /* frec. con que se llama la planif. (ms) */ 

11054 #define SCHEDRATE (MILLISEC*HZ/1000)/* # tics por planificación */ 

11055 

11056 /* parámetros del reloj. */ 

11057 #define COUNTERFREQ (2*TIMERFREQ) /* frec. del contador con onda cuadrada*/ 

11058 #define LATCH COUNT 0x00 /* ccOOxxxx, c = canal, x = cualq. */ 

11059 #define SQUARE WAVE 0x36 /* ccaammmb, a = access, m = modo, b = BCD */ 

11060 /* 11x11, 11 =LSB luego MSB,xll= ondac. */ 

11061 #define TIMER COUNT ((unsigned) (TIMER FREQ/HZ)) /* val. inic. contador*/ 

11062 #define TIMER FREQ 1193182L /* frec. reloj p/temporiz. en PC y AT */ 

11063 

11064 #define CLOCK ACK BIT 0x80 /* bit acuse interrupción de reloj PS/2 */ 

11065 

11066 /* Variables de la tarea de reloj. */ 

11067 PRIVATE dock t realtime; /* reloj de tiempo real */ 

11068 PRIVATE time t boot time;/* segundos desde arranque del sist. */ 

11069 PRIVATE dock t next alarm; /* tiempo probable de sigo alarma */ 

11070 PRIVATE message me; -/* bufo mensaje p/entrada y salida */ 

11071 PRIVATE int watchdog_proc; /* contiene proc_nr en llamo de *watch_dog[ ]*/ 

11072 PRIVATE watchdogt watch_dog[NR_TASKS+NR_PROCS]; 

11073 

11074 /* Variables empleadas por las tareas de reloj y de alarma síncrona */ 

11075 PRIVATE int syn_al_alive= TRUE; /* no despertar syn_alrm_task antes inited*/ 

11076 PRIVATE int syn_table[NR_TASKS+NR_PROCS]; /* qué tareas rec. CLOCKINT*/ 

11077 

11078 /* Variables que el manejador de interrupciones modifica */ 

11079 PRIVATE clock_t pending_ticks; /* tics vistos sólo por nivel bajo */ 

11080 PRIVATE int schedticks = SCHEDRATE; /* contador: si 0, llamar planif. */ 

11081 PRIVATE struct proc *prev_ptr; -/* últ. proc. usuario ejec. por tarea reloj */ 11082 

11083 FORWARD PROTOTYPE( void common setalarm, (int proe nr, 

11084 -long delta_ticks, watchdog_t fuction)); 

11085 FORWARD _PROTOTYPE( void do_clocktick, (void)); 

11086 FORWARD _PROTOTYPE( void do_get_time, (void)); 

11087 FORWARD PROTOTYPE( void do getuptime, (void)); 

11088 FORWARD -PROTOTYPE( void do-set time, (message *m_ptr)); 

11089 FORWARD =PROTOTYPE( void do=setalarm, (message *m_ptr)); 

11090 FORWARD _PROTOTY~E( void init clock, (void)); 

11091 FORWARD _PROTOTYPE( void cause_alarm, (void)); 

11092 FORWARD _PROTOTYPE( void do setsyn alrm, (message *m_ptr)); 

11093 FORWARD _PROTOTYPE( int clock handler, (int irq)); 

11094 

11095 /*========================================= == ==============* 

11096 * clock_task * 

11097 *============================= == =============== == =============*/ 

11098 PUBLIC void clock_task() 

11099 { 

11100 /* Programa principal de la tarea de reloj. Corrige realtime 

11101 * sumando tics pendientes vistos sólo por el servicio de ints., luego 

11102 * determina cuál de las 6 posibles llamadas es examinando ’mc.mjype'. 

11103 * Luego despacha. 

11104 */ 
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11105 

11106 intopcode; 

11107 

11108 init_clock(); /* inicializ. tarea de reloj */ 

11109 

11110 /* Ciclo principal: Obtener trabajo, procesarlo, a veces responder. */ 

11111. while(TRUE) { 

11112 receive(ANY, &mc); /* obtener un mensaje */ 

11113 opcode = mc.m_type; /* extraer cód. de función */ 

11114 

11115 lock(); 

11116 realtime += pending_ticks; /* transí, tics de manej. de bajo nivel */ 

11117 pending_ticks = 0; /* pino tener que preocupamos p/ellos */ 


11118 unlock(); 

11119 

11120 switch (opcode) { 

11121 case HARDINT: do_clocktick()j break; 

11122 case GET UPTIME: do_getuptime(); break; 

11123 case GET TIME: do_get_time(); break; 

11124 case SET TIME: do_set_time(&mc); break; 

11125 case SET ALARM: do_setalarm(&mc); brearj 

11126 case SET_SYNC_AL:do_setsyn_alrm(&mc); break; 


11127 default: panic("clock task got bad message", mc.m_type); 

11128 } 

11129 

11130 /* Enviar respuesta, excepto por tic de reloj. */ 

11131 mc.mtype = OK; 

11132 if (opcode 1= HARD INT) send(mc.m_source, &mc); 

11133 } 

11134 } 


11137 /*===================== == ========== = ===== 

11138 * do_clocktick 

11139 *======================= — == == ============= 

11140 PRIVATE void do_clocktick() 

11141 { 

11142 /* A pesar de su nombre, esta rutina no se invoca en cada tic. Se invoca 

11143 * en los tics en los que hay que efectuar mucho trabajo. 

11144 */ 

11145 

11146 register struct proc *rp; 

11147 register int proc_nr; 

11148 


11149 

11150 

11151 

11152 

11153 

11154 

11155 

11156 

11157 

11158 

11159 

11160 
11161 
11162 

11163 

11164 


if (next_alarm <= realtime) { 

/* Tal vez sonó una alarma, pero el proc pudo haber salido, verificar. */ 
next alarm = LONG MAXj /* comenzar a calco sigo alarma */ 
for (rp = 8EG PROC ADDR; rp < END PROC ADDR; rp++) { 
if (rp->p_alarm 1= 0) { 

/* Ver si se llegó a este tiempo de alarma. */ 
if (rp->p_alarm <= realtime) { 

/* Un temporiz. llegó a 0. Si es proc. 

* usuario, enviarle señalj si es tarea, 

* inv. fimGo antes especif. por la tarea. 

*/ 

proc_nr = proc_number(rp); 
if (watch_dog[proc_nr+NR_TASKS]) { 
watchdog_proc= proc_nr; 

(*watch_dog[proc_nr+NR_TASKS])(); 

} 


*/ 
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11165 else 

11166 cause_sig(proc_nr, SIGALRM); 

11167 rp->p_alarm = 0; 

11168 

11169 

11170 

11171 

11172 

11173 

11174 } 

11175 } 

11176 

11177 /* Si un proc. usuario se ha ejecutado demasiado tiempo 

11178 if (—sched_ticks = 0) { 

11179 if (bill_ptr = prev_ptr) lock_sched(); 

11180 sched ticks = SCHED RATE; 

11181 prev_ptr = bill_ptr; 

11182 } 

11183 } 

11186 /*===== === ====== == = 

11187* do_getuptime 

11188 *====== - ===== ^= ========= ^ = = == == 

11189 PRIVATE void do_getuptime() 

11190 { 

11191 /* Obtener y devolver el tiempo desde arranque en tics. */ 

11192 

11193 mc.NEW TIME = realtime; /* tiempo desde arranque actual */ 

11194} 

11197 /*=================== == ============== = ====== 

11198* get_uptime 

11199 *====================== ==■= = == = == ============== 

11200 PUBLIC clock t get_uptime() 

11201 { 

11202 /* Obt. y devolver tiempo desde arranque en tics. Fuñe, diseñada 

11203 * para ser llamada desde otras tareas para obtener el tiempo 

11204* sin el gasto que implican los mensajes. Debe tener cuidado con pending_ticks. 

11205 */ 

11206 

11207 clock_t uptime; 

11208 

11209 lock(); 

11210 uptime = realtime + pending_ticks; 

11211 unlockO; 

11212 retum(uptime); 

11213 } 


11217* do_get_time 

11218 *====== - = — ========= = ====== == ========== 

11219 PRIVATE void do_get_time() 

11220 { 

11221 /* Obtener y devolver tiempo de reloj actual en segundos. */ 

11222 

11223 me.NEW TIME = boot time 

11224 } 


, escoger otro. */ 

/* proc. se ejec. demasiado */ 
/* restablecer cuanto */ 

/* nuevo proceso anterior */ 


/* Determinar cual alarma sigue. */ 
if (rp->p_alarm 1=0 && rp->p_alarm < next_alarm) 
nextalarm = rp->p_alarm; 


+ realtime/HZ; 


/* tiempo real actual */ 
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11227 /*===== ======== = ======= = === == = = == 

11228 * do_set_time 

11229 ♦== = == = ============= = ======== = === = = === === ==== 

11230 PRIVATE void do_set_time(m_ptr) 

11231 message *m_ptr; /* apunto al mensaje de solicitud */ 

11232 { 

11233 /* Poner reloj tiempo real. Sólo el superusuario puede usar esta llamada. */ 

11234 

11235 boot time = m_ptr->NEW_TIME -realtime/HZ; 

11236 } 

11239 /*==== ==== == = == = == ===== === == = ==== = 

11240 * do_setalarm 

11241 *============== = === = = = = == == = = = === == = = = === = = = = = == = = = ====== 

11242 PRIVATE void do_setalarm(m_ptr) 

11243 message *m_ptr; /* apunto al mensaje de solicitud */ 

11244 { 

11245 /* Un proceso pide una señal de alarma o una tarea pide que se invoque 

11246 * una tunco vigilante dada después de cierto intervalo. 

11247 */ 

11248 

11249 register struct proc *rp; 

11250 int proc_nr; /* qué proc. quiere alarma */ 

11251 long delta_ticks; /* ¿en cuántos tics la quiere? */ 

11252 watchdog_t function; /* tunco por llamar (sólo tareas) */ 

11253 

11254 /* Extraer los parámetros del mensaje. */ 

11255 proc nr = m_ptr->CLOCK_PROC_NR; /* proc. que interrumpir después */ 

11256 delta ticks = m_ptr->DELTA_TICKS; 1* cuántos tics esperar */ 

11257 function = (watchdog_t) m_ptr->FUNC_TO_CALL; 

11258 /* tunco por llamar (sólo tareas) */ 

11259 rp = proc_addr(proc_nr); 

11260 mc.SECONDSLEFT = (rp->p_alarm = 0 ? 0 : (rp->p_alarm -realtime)/HZ ); 

11261 if (!istaskp(rp)) function= 0; 1 * procs. usu. son señalizados */ 

11262 common_setalarm(proc_nr, delta_ticks, function); 

11263 } 




11266/*==============================================================* 

11267 * do_setsyn_alrm * 

11268 * == ============== = = = ======= == = = === = = = === = = == == == = ==== */ 

11269 PRIVATE void do_setsyn_alrm(m_ptr) 

11270 message *m_ptr;/* apunto a mensaje de solicitud */ 

11271 { 

11272 /* Un proceso pide una alarma síncrona. 

11273 */ 

11274 

11275 register struct proc *rp; 

11276 int proc_nr; /* qué proc. pide la alarma */ 

11277 long delta_ticks; 1 * ¿en cuántos tics la pide? */ 

11278 

11279 /* Extraer los parámetros del mensaje. */ 

11280 proc_nr = m_ptr->CLOCK_PROC_NR; 1 * proc. que interrumpir después */ 

11281 delta ticks = m_ptr->DELTA_TICKS; 1* cuántos tics esperar */ 

11282 rp = proc_addr(proc_nr); 

11283 mc.SECONDS LEFT = (rp->p_alarm = 0 ? 0 : (rp->p_alarm -realtime)/HZ ); 

11284 common_setalarm(proc_nr, delta_ticks, cause_alarm); 
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11285 


} 


11288 /*======= == = 

11289 * 

11290 *==================== 

11291 PRIVATE yoid common_setalarm(proc_nr, delta_ticks, function) 


commonsetalarm 


/* qué proc. pide la alarma */ 

/* ¿en cuántos tics la pide? */ 

/* tunco por llamar (0 si se debe 
* llamar cause_sig) */ 


11292 int proc_nrj 

11293 long delta_tickSj 

11294 watchdog t function; 

11295 

11296 { 

11297 /* Terminar trabajo de do_set_alarm y do_setsyn_alrm. Registrar solicitud 

11298 * de alarma y ver si es la sigo alarma que se necesita. 

11299 */ 

11300 

11301 register struct proc *rp; 

11302 

11303 rp = proc_addr(proc_nr); 

11304 rp->p_alarm = (delta_ticks = 0 ? 0 : realtime + delta_ticks); 

11305 watch_dog[proc_nr+NR_TASKSl = function; 

11306 

11307 /* ¿Cuál alarma sigue? */ 

11308 nextalarm = LONGMAX; 

11309 for (rp = BEG PROC ADDR; rp < END PROC ADDR; rp++) 

11310 if(rp->p_alarm != 0 && rp->p_alarm < next_alarm)next_alarm=rp->p_alarm; 

11311 

11312 } 


11315 /*========================================= 

11316 * cause_alarm 

11317 *== == = = ===== = ======= == = == = === === = == = ===== = = 

11318 PRIVATE void cause_alarm() 

11319 { 

11320 /* Rutina invocada si un temporiz. llegó a 0 y el proc. solicitó alarma 

11321 * síncrona. El núm. proc. está en la varo global watchdog_proc (HACK). 

11322 */ 

11323 messagemess; 

11324 

11325 syn_table[watchdog_proc + NR_TASKS1= TRUEj 

11326 if (!syn_al_alive) send (SYNALRMTASK, &mess)j 

11327 } 


=*/ 


11330 /*============================================== = ==============* 

11331 * syn_alrm_task * 

11332 ♦== = =============== = ==== ■ :- -. ===== == =============== == ==============♦/ 

11333 PUBLIC void syn_alrm_task() 

11334 { 

11335 /* Programa principal de la tarea de alarma síncrona. 

11336 * Esta tarea sólo recibe mensajes de cause_alarm en la tarea de reloj. 

11337 * Envía un mensaje CLOCK_INT a un proc. que solicitó una syn_alrm. 

11338 * Las alarmas síncronas, a diferencia de las señales o de la activación 

11339 * de un vigilante, son recibidas por un proceso cuando está en una parte 

11340 * conocida de su código, es decir, cuando ha emitido una llamada 

11341 * para recibir un mensaje. 

11342 */ 

11343 

11344 message mess; 
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11345 int work_done; /* ¿listo para dormir? */ 

11346 int *al_ptr; /* apuntador en syn_table */ 

11347 int i; 

11348 

11349 syn_al_alive= TRUE; 

11350 for (i= 0, al_ptr= syn table; i<NR_TASKS+NR_PROCS; i++, al_ptr++) 

11351 *al_ptr= FALSE; 

11352 

11353 while (TRUE) { 

11354 work_done= TRUE; 

11355 for (i= 0, al_ptr= syn table; i<NR_TASKS+NR_PROCS; i++, al_ptr++) 

11356 if (*al_ptr) { 

11357 *al_ptr= FALSE; 

11358 mess.m_type= CLOCK_INT; 

11359 send (i-NR_TASKS, &mess); 

11360 work_done= FALSE; 

11361 } 

11362 if (work_done) { 

11363 syn_al_alive= FALSE; 

11364 receive (CLOCK, &mess); 

11365 syn_al_alive= TRUEj 

11366 } 

11367 } 

11368 } 

11371 /*======= = = = ====== == ==== = ===== = = ==== === = =* 

11372 * clock_handler * 

11373 ♦ ==== ==== ====== ==== ====== === ========== ♦/ 

11374PRIVATE int clock_handler(irq) 

11375int irq; 

11376 { 

11377 /* Se ejecuta cada tic del reloj (cada vez que el chip temporiz. genera 

11378 * una interrupción). Hace un poco de trabajo para que la tarea de reloj 

11379 * no tenga que invocarse en cada tic. 

11380 * 

11381 * Conmutar contexto a do_clocktick si sonó una alarma. También 

11382 * conmutar ahí para replanificar si la replanificación va a hacer algo. 

11383 * Esto sucede cuando 

11384* (1) el cuanto expiró 

11385 * (2) el proc. actual recibió cuanto completo (isegún reloj!) 

11386 * (3) algo más está listo para ejecutarse. 

11387 * También llamar TTY y PRINTER Y dejar que hagan lo que sea necesario. 

11388 * 

11389 * Se accede a muchas variables globales y estáticas aquí. Se debe justificar 

11390 * la seguridad de esto. Casi ninguna se modifica aquí: 

11391 * k_reenter: 

11392 * Ésta indica sin peligro si la int. de reloj está anidada. 

11393 * proc_ptr, bill_ptr: 

11394 * Éstas se usan p/contabil. No importa si proc.c las modifica 

11395 * siempre que sean apunto válidos, ya que en peor caso 

11396 * se cobraría al proc. anterior. 

11397 * next_alarm, realtime, sched_ticks, bill_ptr, prev_ptr, 

11398 * rdy_head[USER Q]: 

11399 * Éstas se prueban p/decidir si invocar interrupt(). 

11400 * No importa si la prueba es (raras veces) al revés por 

11401 * competencia, ya que el procesam. de ~lto nivel sólo 

11402 * se retrasará un tic, o se llamará innecesariamente el alto nivel. 

11403 * Las variables que se modifican requieren más cuidado: 

11404 * rp->user_time, rp->sys_time: 
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11405 * 

11406* 

11407* 

11408* 

11409* 

11410* 

11411 * 

11412* 

11413* 

11414* 

11415* 

11416* 

11417* 

11418* 

11419* 

11420 * 

11421 * ¿Valen la pena estas complicaciones? Bueno, hacen el sistema 15% 

11422 * más rápido en una 8088 de 5MHz, y facilitan mucho la depuración, 

11423 * pues no hay conmutaciones de tarea en un sistema inactivo. 

11424 */ 

11425 

11426 register struct proc *rp; 

11427 register unsigned ticks; 

11428 clock_t now; 

11429 

11430 if(ps_mca) { 

11431 /* Acusar recibo de la interrupción de reloj PS/2. */ 

11432 out_byte(PORT_B, in_byte(PORT_B) 1 CLOCK ACK BIT); 

11433 } 

11434 

11435 /* Actualizar tiempos de usuario y sistema contabilizados. 

11436 * Primero cobrar t.iempo de usuario al proc. actual. 

11437 * Si el proc. actual no es el facturable (p.ej. si es una tarea), cobrar 

11438 * al proc. facturable tiempo de sistema también. Así, el tiempo de usuario 

11439 * de la tarea no tacto es el tiempo de sist. del usuario facturable. 

11440 */ 

11441 if (k_reenter 1=0) 

11442 rp = procaddr(HARDWARE); 

11443 else 

11444 rp = proc_ptr; 

11445 ticks = lost_ticks + 1; 

11446 lost_ticks = 0; 

11447 rp->user_time += ticks; 

11448 if (rp 1= bill_ptr && rp 1= proc_addr(IDLE)) bill_ptr->sys_time += ticks; 

11449 

11450 pending_ticks += ticks; 

11451 now = realtime + pending_ticks; 

11452 if (tty_timeout <= now) tty_wakeup(now); /* quizá despertar TTV */ 

11453 pr_restart(); /* quizá reinic. impresora */ 

11454 

11455 if (next_alarm <= now 11 

11456 sched_ticks = 1 && 

11457 bill_ptr = prev_ptr && 

11458 rdy_head[USER Q] NNILPROC) { 

11459 interrupt(CLOCK); 

11460 retum 1; /* Rehabilitar interrupciones */ 

11461 } 

11462 

11463 if (—sched_ticks = 0) { 

11464 /* Si bill_ptr = prev_ptr, no hay usuarios listos, no neces 


Éstas se protegen con candados explícitos en system.c. 

No se protegen debidamente en dmp.c (incremento no 
atómico), pero eso no importa. 
pending_ticks: 

Se protege con candados explícitos en clock.c. 

No actualizar realtime directamente, pues hay demasiadas 
referencias a ella para cuidar fácilmente. 

lost_ticks: 

Tics de reloj contados fuera de la tarea de reloj. 
sched_ticks, prev_ptr: 

Al actualizo éstas se compite con cód. similar en do_clocktick(). 
No hace falta candado, porque si algo malo sucede (como 
sched_ticks negativo), el cód. de do_clocktick() restaurará las 
variables a valores razonables, y no importa un sched() faltante 
o extra ocasional. 


5. schedQ. */ 
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11465 sched ticks = SCHED RATE; 7 * restablecer cuanto *7 

11466 prev_ptr = bill_ptr; 7 * nuevo proceso previo *7 

11467 } 

11468 retum 1; 7 * Reenable dock interrupt *7 

11469 } 

11471 1*=========================================================== 


11472 * init_clock .* 

11473 *================================================================*7 


11474 PRIVATE void init_clock() 

11475 { 

11476 7 * Inicializar canal 0 del temporizador 8253A a p.ej. 60 Hz. *7 

11477 

11478 out byte (TIMER MODE , SQUAREWAVE);/* ejec. continua de temporiz. *7 

11479 out_byte(TIMER0, TIMERCOUNT); 7 * cargar byte bajo temporiz. *7 

11480 out_byte(TIMER0, TIMER COUNT >> 8); /* cargar byte alto temporiz. */ 

11481 put_irq_handler(CLOCK_IRQ, clock_handler); 7* fijar manej. de ints. *7 

11482 enable_irq(CLOCK_IRQ); 7 * listo para ints. de reloj *7 

11483 } 

114867*===================================== 

11487 * clock_stop 

11488 *===================================== 

11489 PUBLIC void clock_stop() 

11490 { 

11491 1 * Restablecer reloj a la frec. de BIOS (para rearranque) *1 

11492 

11493 out_byte(TIMER_MODE, 0x36); 

11494 out_byte(TIMER0, 0); 

11495 out_byte(TIMER0,0); 

11496 } 

114997*===================================== 

11500 * milli_delay 

11501*===================================== 

11502 PUBLIC void milli_delay(millisec) 

11503 unsigned millisec; 

11504 { 

11505 7 * Retardo de algunos milisegundos. *7 

11506 

11507 struct milli_state ms; 

11508 

11509 milli_start(&ms); 

11510 while (milli_elapsed(&ms) < millisec) {} 

11511 } 



11513 7*=== 


11514* milli_start * 

11515 *==================================================================*; 


11516 PUBLIC void milli_start(msp) 

11517 struct milli_state *msp; 

11518 { 

11519 7 * Prepararse para llamadas a milli_elapsed(). *7 

11520 

11521 msp->prev_count = 0; 

11522 msp->accum_count = 0; 

11523 } 
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115267*==============================================================* 

11527* milli_elapsed * 

11528 *===============================================================*7 

11529 PUBLIC unsigned milli_elapsed(msp) 

11530 struct milli_state *msp; 

11531 { 


11532 7 * Devolver el número de milisegundos desde la llamada a milli_start(). 

11533 * Debe escrutarse rápidamente. 

11534 *7 

11535 unsigned count; 

11536 

11537 7 * Leer contador de canal 0 del temporiz. 8253A. El contador 

11538 * se decrementa a 2 x la frec del temporiz. (un ciclo por cada mitad 

11539 * de la onda cuadrada). El contador normalmente tiene un valor 

11540 * entre 0 y TIMER_COUNT, pero antes de que la tarea del reloj 

11541 * se haya inicializado su valor máx. es 65535, fijado por BIOS. 

11542 *7 

11543 out_byte (TIMERMODE, LATCH COUNT); 7 * hacer chip copiar count en latch *7 

11544 count = in_byte(TIMER0); 7 * cuenta reg. continúa durante lectura *7 

11545 count 1= in_byte(TIMER0) « 8; 

11546 

11547 7 * Sumar diferencia entre cuenta previa y nueva a menos que el contador 

11548 * haya aumentado (reinic. su ciclo). Podríamos perder un tic de v~z 

11549 * en cuando, pero no necesitamos precisión de ms. 

11550 *7 

11551 msp->accum_count += count <= msp->prev_count ? (msp->prev_count -count): 1; 

11552 msp->prev_count = count; 

11553 

11554 retum msp->accum_count 7 (TIMERFREO 7 1000); 

11555 } 
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11600 

11601 

11602 

11603 

11604 

11605 

11606 

11607 

11608 

11609 

11610 
11611 
11612 

11613 

11614 

11615 

11616 

11617 

11618 
11619 


#define TTY IN BYTES 

#define TAB_SIZE 8 
#define TAB MASK 7 

#define ESC’\33’ 

#define 0_NOCTTY 00400 
#define 0_NONBLOCK 04000 


7 * tamaño cola entrada tty *7 
7 * distancia entre tabulaciones *7 
7 * máscara para calco pos. de tab. *7 

7 * escape *7 

7 * de <fcntl.h>, o cc se ahogará *7 


tty.h -Terminales *7 
256 


typedef _PROTOTYPE( void (*devfün_t), (struct tty *tp)); 
typedef _PROTOTYPE( void (*devfunarg_t), (struct tty *tp, int c) ); 

typedef struct tty { 

int tty_events; 7 * fijar cuándo TTY debe examinar esta línea *7 

7 * Cola de entrada. Las digit. se guardan aquí mientras un prog. las lee. *7 
ul6_t *tty_inhead; 7 * apunto a donde va el sigo carácter *7 

ul6_t *tty_intail; 7 * apunto al sigo caro que se dará al prog. *7 
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/* # cars. en cola de entrada */ 

/* # "saltos línea" en cola entrada */ 

/* rutina p/leer de bufs. bajo nivel */ 
/* cancelar entradas de dispositivos */ 
/* # mín. cars. solic. en cola ent. */ 

/* tiempo entrada estará disponible */ 
/* p/lista ttys con temporiz. activos */ 


/* rut. p/iniciar salida de disp. real */ 
/* rut. p/hacer eco de cars. introd. */ 
/* cancelar salida de disp. actual */ 

/* que el disp. envíe un corte */ 


int tty_incount; 
int tty_eotct; 
devfun_t tty_devread; 
devfun_t tty_icancel; 
int tty min; 
dock t tty time; 
struct tty *tty_timenext; 

/* Sección de salida. */ 
devfun_t tty_devwrite; 
devfunarg_t tty_echo; 
devfun_t tty_ocancel; 
devfun_t tty_break; 


/* parámetros y situación de la terminal. */ 

int tty_position; /* pos. actual en pantalla p/eco */ 

char tty_reprint; /* 1 si eco de entradas mal, 0 sí ok */ 

char tty_escaped; /* 1 si llegó LNEXT (AV), 0 si no */ 

char tty_inhibited; /* 1 si llegó STOP (AS) (detiene salida) */ 

char tty_pgrp; /* # ranura del proceso que controla */ 

char tty_openct; /* cuenta de aperturas de esta tty */ 

/* Aquí se guarda info. sobre solicitudes de E/S incompletas. */ 

char tty inrepcode; /* cód. respuesta, TASK REPLYo REVIVE */ 

char tty_incaller; /* proceso que invocó (usualmente FS) */ 

char tty_inproc; /* proc. que quiere leer de tty */ 

vir_bytes tty_in_vir; /* dirección virtual p/enviar datos */ 

int tty_inleñ; /* ¿cuántos más cars. se necesitan? */ 

int tty_incum; /* # cars. introducidos hasta ahora */ 

char tty outrepcode; /* cód. respuesta, TASK REPLY o REVIVE */ 

char tty_outcaller; /* proceso que invocó (usualmente FS) */ 

char tty_outproc; /* proc. que quiere escribir en tty */ 

vir_bytes tty_out_vir; /* dirección virtual de origen datos */ 

int tty_outleft; /* # cars. aún por enviar */ 

int tty_outcum; /* # cars. enviados hasta ahora */ 

char tty_iocaller; /* proceso que invocó (usualmente FS) */ 

char tty_ioproc; /* proc. que quiere hacer un ioctl */ 

int tty_ioreq; /* código de solicitud de ioctl */ 

vir_bytes tty_iovir; /* dir. virtual de buffer de ioctl */ 


/* Diversos. */ 
devfun_t tty_ioctl; 
devfun_t tty_close; 
void *tty_priv; 
struct termios tty_termios; 
struct winsize tty_winsize; 


/* fijar velo línea, etc. en nivel disp. */ 
/* decir a dispositivo que tty cerrada */ 
/* apunto a datos privados por disp. */ 
/* atributos de terminal */ 

/* tamaño ventana (# líneas y # cois.) */ 


ul6_t tty_inbuf[TTY_IN_BYTES];/* buffer de entrada de tty *, 
} tty t; 


EXTERN tty t tty table [NR_CONS+NR_RS_LINES+NR_PTYS]; 


/* Valores para los campos. */ 

#define NOT ESCAPED 0 

#define ESCAPED 1 

#define RUNNING 0 

#define STOPPED 1 

/* Campos y banderas p/caracteres e 
#define IN CHAR OxOOFF 


caro previo no es LNEXT (AV) */ 

:aro previo fue LNEXT (AV) */ 
ío caro STOP (AS) p/detener salida */ 
.e tecleó STOP (AS) p/detener salida */ 


la cola de entrada. */ 

/* 8 bits bajos s( 


i el carácter mismo */ 
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11680 #defme IN_LEN OxOFOO /* long. de caro si se hizo eco de él */ 

11681 #defme INLSHIFT 8 /* longitud = (c & IN_LEN) » INLSHIFT */ 

11682 #define IN_EOT Ox 1000 /* caro es salto de línea (’D, LF) */ 

11683 #defme IN_EOF 0x2000 /* caro es EOF (’D), no devolv. a usuario */ 

11684 #define IN_ESC 0x4000 /* escapado con LNEXT (’V), no interpretar */ 

11685 

11686 /* Tiempos y plazos. */ 

11687 #defme TIMENEVER ((clock_t) -1 < 0 ? (clock_t) LONGMAX : (clock_t) -1) 

11688 #defme force_timeout() ((void) (tty_timeout = 0)) 

11689 

11690 EXTERN tty_t *tty_timelist; /* lista de ttys con temporiz. activos */ 

11691 

11692 /* Número de elementos y límite de un buffer. */ 

11693 #defme buflen(buf) (sizeof(buf) / sizeof((buf)[0])) 

11694 #defme bufend(buf) ((buf) + buflen(buf)) 
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11700 /* Este archivo contiene el controlador en sof. de la terminal, tanto consola 

11701 * IBM como terms. ASCII normales. Sólo maneja la parte indep. del disp. 
11702* de una TTV. Las partes dependientes están en console.c, rs232.c, etc. 

11703 * El arch. tiene dos ptos. de entrada princ., tty_task() y tty_wakeup(), 

11704* Y varios ptos. entrada menores para uso del cód. dependo del disp. 

11705 * 

11706* La parte indep. del disp. acepta entradas de "teclado" de la parte dependo 
11707* del disp., procesa entradas (interpreta teclas especiales) y las envía 
11708* a un proc. que lee de la TTV. Las salidas a TTV se envían al cód. 

11709* dependo del disp. para procesarse y exhibo en "pantalla". El procesam. 

11710* de entradas lo hace el disp. que invoca 'in_process' con los caro de 
11711 * entrada; el procesam. de salidas puede ser hecho por el disp. 

11712* mismo o llamando ’out_process'. TTV se ocupa de poner en cola 
11713* entradas, el disp. pone en cola salidas. Si un disp. recibe una señal 
11714* extema, como una interrupción, hace que la tarea CLOCK ejecute 
11715* tty_wakeup() para (adivinó) despertar la TTV y que verifique 
11716* si puede continuar la entrada o la salida. 

11717 * 


11718* Los mensajes válidos y sus parámetros son: 


11719 

11720* 

11721* 

11722* 

11723* 

11724* 

11725* 

11726* 

11727 

11728* 

11729* 

11730* 

11731* 

11732* 

11733* 

11734* 


HARD_INT: terminó salida o llegó entrada 
DEV_READ: un proceso quiere leer de una terminal 
DEV_WRITE: un proceso quiere escribir en una terminal 

DEVIOCTL: un proc. quiere cambiar los parámetros de una terminal 
DEV OPEN: se abrió una línea de tty 
DEV CLOSE: se cerró una línea de tty 

CANCEL: terminar inmediato llamada a sist. incompleta previa 


m type TTV_LINE PROC_NR COUNT TTV_SPEK TTV FLAGS ADDRESS 


| HARD INT | 

1 J . 1 

1 1 

. + . + . 

| DEV READ |disp sec 

| # proc | cuenta | 

|0 NONBLOCK | ap buf | 


DEVWRITE |dispsec |#proc |cuenta | | 


| ap buf 
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11735* 

11736* 

11737* 

11738* 

11739* 

11740* 

11741’ - 
11742* 

11743*- 

11744 */ 

11745 

11746 #include "kemel.h" 

11747 #include <termios.h> 

11748 #include <sys/ioctl.h> 

11749 #include <signal.h> 

11750 #include <minix/callnr.h> 

11751 #include <minix/com.h> 

11752 #include <minix/keymap.h> 

11753 #include "tty.h" 

11754 #include "proc.h" 

11755 

11756/* Dirección de una estructura tty. */ 

11757 #defme tty_addr(line) (&tty_table[line]) 

11758 

11759/* Primeros núms. secundo para las diversas clases de dispositivos TTY. */ 

11760 #define CONSMINOR 0 

11761 #defme LOG MINOR 15 

11762 #defme RS232 MINOR 16 

11763 #defme TTYPXMINOR 128 

11764 #defme PTYPXMINOR 192 

11765 

11766/* Macros para tipos de tty mágicos. */ 

11767 #defme isconsole(tp) ((tp) < tty_addr(NR_CONS)) 

11768 

11769/* Macros para apuntadores a estructuras de tty mágicas. */ 

11770 #defme FIRST TTY ttyaddr(0) 

11771 #defme END_TTY tty=addr(sizeof(tty_table) 
/ sizeof(tty_table[0])) 

11772 

11773 /* Existe un dispositivo si está definida por lo menos su función ’devread'. */ 

11774 #define tty_active(tp) ((tp)->tty_devread 1=NULL) 

11775 

11776 /* Las líneas RS232 o seudoterminales pueden contigo completamente. */ 

11777 #if NRRSLINES == 0 

11778 #define rs_init(tp) ((void) 0) 

11779 #endif 

11780 #if NRPTYS = 0 

11781 #define pty_init(tp) ((void) 0) 

11782 #define do_pty(tp, mp) ((void) 0) 

11783 #endif 

11784 


11785 FORWARD _PROTOTYPE( void do cancel, (tty t *tp, message *m_ptr) ); 

11786 FORWARD _PROTOTYPE( void do ioctl, (tty t *tp, message *m_ptr) ); 

11787 FORWARD PROTOTYPE( void do open, (tty t *tp, message *m_ptr) ); 

11788 FORWARD =PROTOTYPE( void do=close, (tty t *tp, message *m_ptr) ); 

11789 FORWARD _PROTOTYPE( void do read, (tty t *tp, message *m_ptr) ); 

11790 FORWARD _PROTOTYPE( void do_write, (tty t *tp, message *m_ptr) ); 

11791 FORWARD PROTOTYPE( void in transfer, (tty t *tp) ); 

11792 FORWARD =PROTOTYPE( int echo, (tty_t *tp, int ch) ); 

11793 FORWARD _PROTOTYPE( void rawecho, (tty t *tp, int ch) ); 

11794 FORWARD _PROTOTYPE( int back over, (tty t *tp) ); 


1- 

DEV IOCTL 

|disp se. 

c |# proc 

|cod fuñe | borra etc 

¡banderas | 


DEVOPEN 

|disp sei 

c |# proa 

|0_NOCTTY| 

1 1 


DEV CLaSE 

|disp sei 

c | # proc 

1 1 

1 1 


| CANCEL 

|disp se. 

c |# proc 


1 ' 1 
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11795 FORWARD _PROTOTYPE( void reprint, (tty_t *tp) ); 

11796 FORWARD _PROTOTYPE( void dev_ioctl, (tty t *tp) ); 

11797 FORWARD _PROTOTYPE( void setattr, (tty t *tp) ); 

11798 FORWARD _PROTOTYPE( void tty icancel, (tty_t *tp) ); 

11799 FORWARD _PROTOTYPE( void tty init, (tty_t *tp) ); 

11800 FORWARD _PROTOTYPE( void settimer, (tty_t *tp, int on) ); 

11801 

11802 /* Atributos predeterminados. */ 

11803 PRIVATE struct termios termios_defaults = { 


11804 TINPUT DEF, TOUTPUT DEF, TCTRL DEF, TLOCAL DEF, TSPEEDDEF, TSPEEDDEF, 

11805 { 

11806 TEOFDEF, TEOLDEF, TERASEDEF, TINTRDEF, TKILLDEF, TMINDEF, 

11807 TQUITDEF, TTIMEDEF, TSUSP_DEF, TSTARTDEF, TSTOPDEF, 

11808 TREPRINTDEF, TLNEXTDEF, TDISCARDDEF, 

11809 }, 

11810 }; 

11811 PRIVATE struct winsize winsize_defaults; /* = puros ceros */ 

11812 

11813 

11814 /*============================================== = ==============* 

11815* tty_task * 

11816 *== = = = ======= = === = = = == == === = = ===== === = = == = = = = == == == = = = == = === = = = */ 

11817 PUBLIC void tty_task() 

11818 { 

11819 /* Rutina principal de la tarea de terminal. */ 

11820 

11821 message tty_mess; /* buffer p/todos los mensajes entrantes */ 

11822 register tty_t *tp; 

11823 unsigned line; 

11824 

11825 /* Inicializar las líneas de terminal. */ 

11826 for (tp = FIRST TTY; tp < END TTY; tp++) tty ínit(tp); 

11827 

11828 /* Exhibir letrero de inicio de Minix. */ 

11829 printf("Minix %s.%s Copjn-ight 1997 Prentice-Hall, Inc.\n\n", 

11830 OS RELEASE, OS_VERSION); 

11831 printf("Executing in 32-bit protected mode\n\n"); 

11832 

11833 whíle(TRUE) { 

11834 /* Manejar cualesquier eventos en cualquier tty. */ 

11835 for (tp = FIRST TTY; tp < END TTY; tp++) { 

11836 if (tp->tty_events) handle_events(tp); 

11837 } 

11838 

11839 receive(ANY, &tty_mess); 

11840 

11841 /* Una int. de hardware es una invitación a verificar si hubo eventos. */ 

11842 if (tty_mess.m_type == HARD_INT) continué; 

11843 

11844 /* Verificar el número de dispositivo secundario. */ 

11845 fine = tty_mess.TTY_LINE; 

11846 if ((fine -CONS_MINOR) < NR_CONS) { 

11847 tp = tty_addr(line -CONS_MINOR); 

11848 } else 

11849 if (line = LOG MINOR) { 

11850 tp = tty_addr(0); 

11851 } else 

11852 if ((fine -RS232 MINOR) < NR RS LINES) { 

11853 tp = tty_addr(line -RS232_MINOR + NR_CONS); 

11854 } else 








Archivo: src/kemel/tty.c 


EL CÓDIGO FUENTE DE MINIX 


680 


11855 

11856 

11857 

11858 

11859 

11860 
11861. 
11862 

11863 

11864 

11865 

11866 

11867 

11868 

11869 

11870 

11871 

11872 

11873 

11874 

11875 

11876 

11877 

11878 

11879 

11880 
11881 
11882 

11883 

11884 

11885 
11888/ 

11889 

11890 * 


if ((line -TTYPXMINOR) < NRPTYS) { 

tp = tty_addr(line -TTYPX MINOR + NR_CONS + NRRSLINES); 

} else 

if ((line -PTYPXMINOR) < NR PTYS) { 

tp = tty_addr(line -PTYPX MINOR + NR_CONS + NR RS LINES); 
do_pty(tp, &tty_mess); 

continué; /* es una pty, no una tty */ 

} else { 

tp = NULL; 

} 


/* Si el disp. no existe o no está configurado, devolver ENXIO. */ 
if (tp = NULL 11 !tty_active(tp)) { 

tty_reply(TASK_REPLY, tty_mess.m_source, 

tty_mess.PROC_NR, ENXIO); 


continué; 


} 


/* Ejecutar la función solicitada. */ 
switch (tty_mess.m_type) { 


case DEVREAD: 
case DEV WRITE: 
case DEV IOCTL: 
case DEV OPEN: 
case DEVCLOSE: 
case CANCEL: 
default: 


do_read(tp, &tty_mess); break 

do_write(tp, &tty_mess); break 

do_ioctl(tp, &tty_mess); break 

do_open(tp, &tty_mess); break 

do_close(tp, &tty_mess); break 

do_cancel(tp, &tty_mess); break 


tty_reply(TASK_REPLY, tty_mess.m_source, 

tty_mess.PROC_NR, EINVAL); 


do_read 


11891 PRIVATE void do_read(tp, m_ptr) 

11892register tty_t *tp; /* apuntador a struct tty */ 

11893message *m_ptr; /* apunto a mens. enviado a tarea */ 

11894 { 

11895 /* Un proceso quiere leer de una terminal. */ 

11896 intr; 

11897 

11898 /* Comprobar si ya hay un proceso suspendido por lectura, verificar 

11899 * si los parámetros son correctos, efectuar E/S. 

11900 */ 

11901 if (tp->tty_inleft > 0) { 

11902 r = EIO; 

11903 } else 

11904 if (m_ptr->COUNT <= 0) { 

11905 r = EINVAL; 

11906 } else 

11907 if (numap(m_ptr->PROC_NR, (vir bytes) m_ptr->ADDRESS, m_ptr->COUNT) = 0) { 

11908 r = EFAULT; 

11909 } else { 

11910 /* Copiar info. del mensaje a la struct. tty. */ 

11911 tp->tty_inrepcode = TASKREPLY; 

11912 tp->tty_incaller = m_ptr->m_source; 

11913 tp->tty_inproc = m_ptr->PROC_NR; 

11914 tp->tty_in_vir = (vir_bytes) m_ptr->ADDRESS; 


=*/ 
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11915 

11916 

11917 

11918 

11919 

11920 

11921 

11922 

11923 

11924 

11925 

11926 

11927 

11928 

11929 

11930 

11931 

11932 

11933 

11934 

11935 

11936 

11937 

11938 

11939 

11940 

11941 

11942 

11943 

11944 

11945 

11946 

11947 

11948 

11949 

11950 

11951 

11952 

11953 

11954 

11955 

11956 

11957 tty 

11958 } 


tp->tty_inleft = m_ptr->COUNT; 

if (! (tp->tty_termios.c_lflag & ICANON) 

&& tp->tty_termios.C_Cc[VTIME] > 0) { 
if (tp->tty_termioS.C_CC[VMIN] = 0) { 

/* MIN Y TIME especifican temporiz. que termina lectura 
* en TIME/10 seg si no hay bytes disponibles. 

*/ 

lock(); 

settimer(tp, TRUE) j 
tp->tty_min = 1; 
unlock(); 

} else { 

/* MIN Y TIME especifican temporiz. entre bytes que podría 
* tener que cancelarse si no hay bytes aún. 

*i 

if (tp->tty_eotct = 0) { 
lock(); 

settimer(tp, FALSE); 
unlock(); 

tp->tty_min = tp->tty_termios.c_CC[VMIN]; 


} 

/* ¿Algo esperando en buffer de entrada? Despejarlo... */ 
in_transfer(tp); 

/* ...y luego regresar por más */ 
handle_events(tp); 

if (tp->tty_inleft = 0) retum; /* ya se b 

/* No había bytes disponibles en la cola, así que suspender invocador 
* o terminar la lectura si no es bloqueadora. 


if (m_ptr->TTY_FLAGS & 0_NONBLOCK) { 
r = EAGAIN; 

tp->tty_inleft = tp->tty_incum = 0; 

} else { 

r = SUSPEND; 
tp->tty_inrepcode = REVIVE; 


'_reply(TASK_REPLY, m_ptr->m_source, m_ptr->PROC_NR, r); 


/* cancelar la lectura */ 


/* suspender el invocador */ 


11961 /♦================== = ================= = ======= = ======== 

11962* do_write 

11963 *===- — === ^--- . = = ^ ============ = =========================== 

11964 PRIVATE void do_write(tp, m_ptr) 

11965 register tty_t *tp; 

11966 register message *m_ptr; /* apunto a mensaje enviado ; 

11967 { 

11968 /* Un proceso quiere escribir en una terminal. */ 

11969 intr; 

11970 

11971 /* Comprobar si ya hay un proceso suspendido por escritura, verificar 

11972 * si los parámetros son correctos, efectuar E/S. 

11973 */ 

11974 if (tp->tty_outleft > 0) { 


=*/ 


*/ 
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11975 

11976 

11977 

11978 

11979 

11980 

11981 

11982 

11983 

11984 

11985 

11986 

11987 

11988 

11989 

11990 

11991 

11992 

11993 

11994 

11995 

11996 

11997 

11998 

11999 

12000 
12001 
12002 

12003 

12004 

12005 

12006 


r = EIO; 

} else 

if (m_ptr->COUNT <= 0) { 
r = EINVAL; 

} else 

if (numap(m_ptr->PROC_NR, (vir bytes) m_ptr->ADDRESS, m_ptr->COUNT) = 0) { 
r EFAULT; 

} else { 

/* Copiar parámetros del mensaje en la estructura tty. */ 
tp->tty_outrepcode = TASKREPLY; 
tp->tty_outcaller = m_ptr->m_source; 
tp->tty_outproc = m_ptr->PROC_NR; 
tp->tty_out_vir = (virbytes) m_ptr->ADDRESS; 
tp->tty_outleñ = m_ptr->COUNT; 

/* Tratar de escribir. */ 
handle_events(tp); 

if (tp->tty_outleft = 0) retum; /* ya se hizo */ 

/* Imposible escribir algún o todos los bytes, así que suspender 
* invocador o terminar la escritura si es no bloqueadora. 

if (m_ptr->TTY_FLAGS & 0_NONBLOCK) { /* cancelar escritura */ 

r = tp->tty_outcum > 0 ? tp->tty_outcum : EAGAIN; 
tp-^tyoutleñ = tp->tty_outcum = Oj 

} else { 

r = SUSPEND; /* suspender invocador */ 

tp-jqtyoutrepcode = REVIVE; 


tty_reply(TASK_REPLY, m_ptr->m_source, m_ptr->PROC_NR, r); 


12009 /*============================================= = ==============* 

12010 * do_ioctl * 

12011 * - ^ .^:—- = === ========================= = =============================♦/ 

12012 PRIVATE void do_íoctl(tp, m_ptr) 

12013 register tty t *tp; 

12014 message *m_ptr; /* apunto a mensaje enviado a tarea */ 

12015 { 

12016 /* Realizar IOCTL en esta terminal. La llamada al sistema 

12017 * IOCTL maneja las llamadas termios de Posix 

12018 */ 

12019 

12020 int r; 

12021 unión { 

12022 int i; 

12023 /* ya no se usan estos paráms. no Posix, pero se conserva la unión 

12024 * para minimizar diferencias de código con versión compatible hacia atrás 

12025 * struct sgttyb sg; 

12026 * struct tchars te; 

12027 */ 

12028 } param; 

12029 phys_bytes user_phys; 

12030 size_t size; 

12031 

12032 /* Tamaño del parámetro de ioctl. */ 

12033 switch (m_ptr->TTY_REQUEST) { 

12034 caseTCGETS: /* función tegetattr de Posix */ 
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12035 

12036 

12037 

12038 

12039 

12040 

12041 

12042 

12043 

12044 

12045 

12046 

12047 

12048 

12049 

12050 

12051 

12052 

12053 

12054 

12055 

12056 

12057 

12058 

12059 

12060 
12061 
12062 

12063 

12064 

12065 

12066 

12067 

12068 

12069 

12070 

12071 

12072 

12073 


TCSETS: /* función tcsetattr de Posix, opción TCSANOW */ 

TCSETSW: /* función tcsetattr de Posix, opción TCSADRAIN */ 

TCSETSF: /* función tcsetattr de Posix, opción TCSAFLUSH */ 

size = sizeof(struct termios); 


case TCSBRK: 
case TCFLOW: 
case TCFLSH: 
case TIOCGPGRP: 
case TIOCSPGRP: 
size = sizeof(int)j 
break; 


/* función tcsendbreak de Posix 
/* función tcflow de Posix */ 

/* función tcflush de Posix */ 

/* función tcgetpgrp de Posix */ 
/* función tcsetpgrp de posix */ 


case TIOCGWINSZ: /* obtener tamaño ventana (no Posix) */ 

case TIOCSWINSZ: /* fijar tamaño ventana (no Posix) */ 

size = sizeof(struct winsize); 


KIOCSMAP: /* cargar mapa de teclas (ext. de Minix) */ 

size = sizeof(keymap_t); 
break; 


case TIOCSFON: /* cargar fuente (extensión de Minix) */ 

size = sizeof(u8_t [8192]); 


case TCDRAIN: /* función tcdrain de Posix, sin parám. */ 

default: size = 0; 

} 


if (size != 0) { 

user_phys = numap(m_ptr->PROC_NR, (vir bytes) m_ptr->ADDRESS, size); 

if (user_phys = 0) { 

tty_reply(TASK_REPLY, m_ptr->m_source, m_ptr->PROC_NR, EFAULT); 

} 

} 


12074 r = OK; 

12075 switch (m_ptr->TTY_REQUEST) { 

12076 case TCGETS: 

12077 /* Obtener atributos de termios. */ 

12078 phys_copy(vir2phys(&tp->tty_termios), user_phys, (phys_bytes) size); 

12079 break; 

12080 

12081 case TCSETSW: 

12082 case TCSETSF: 

12083 case TCDRAIN: 

12084 if (tp->tty_outlefi > 0) { 

12085 /* Esperar que termine procesam. actual de salidas. */ 

12086 tp->tty_iocaller = m_ptr->m_source; 

12087 tp->tty_ioproc = m_ptr->PROC_NR; 

12088 tp->tty_ioreq = m_ptr->REQUEST; 

12089 tp->tty_iovir = (vir bytes) m_ptr->ADDRESS; 

12090 r = SUSPEND; 

12091 break; 

12092 } 

12093 if (m_ptr->TTY_REQUEST = TCDRAIN) break; 

12094 if (m_ptr->TTY_REQUEST = TCSETSF) tty_icancel(tp); 
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12095 

12096 

12097 

12098 

12099 

12100 
12101 
12102 

12103 

12104 

12105 

12106 

12107 

12108 

12109 

12110 
12111 
12112 

12113 

12114 

12115 

12116 

12117 

12118 

12119 

12120 
12121 
12122 

12123 

12124 

12125 

12126 

12127 

12128 

12129 

12130 

12131 

12132 

12133 

12134 

12135 

12136 

12137 

12138 

12139 

12140 

12141 

12142 

12143 

12144 

12145 

12146 

12147 

12148 

12149 

12150 

12151 

12152 

12153 


/♦SEGUIRSE A LA SIGUIENTE RUTINA*/ 
case TCSETS: 


/* Fijar los atributos de termios. */ 

phys_copy(user_phys, vir2phys(&tp->tty_termios), (phys_bytes) size); 
setattr(tp); 


e TCFLSH: 

phys_copy(user_phys, vir2phys(&param.i), (phys_bytes) size); 
switch (param.i) { 

case TCIFLUSH: ttyicancel(tp); 

case TCOFLUSH: (*tp->tty_ocancel) (tp); 

case TCIOFLUSH: tty_icancel(tp); (*tp->tty_ocancel) (tp);break; 

default: r = EINVAL; 


b k 




case TCFLOW: 

phys_copy(user_phys, vir2phys(&param.i), (phys_bytes) size); 
switch (param.i) { 
case TCOOFF: 
case TCOON: 

tp->tty_inhibited = (param.i == TCOOFF); 

t p- >tt y_ events = i; 

break; 

case TCIOFF: 

(*tp->tty_echo) (tp, tp->tty_termios.c_cc[VSTOP]); 
break; 

case TCION: 

(*tp->tty_echo) (tp, tp->tty_termios.c_CC[VSTARTI); 

default: 
r = EINVAL; 


case TCSBRK: 

if (tp->tty_break != NULL) (*tp->tty_break) (tp); 

case TIOCGWINSZ: 

phys_copy(vir2phys(&tp->tty_winsize), user_phys, (phys_bytes) size); 
break; 

case TIOCSWINSZ: 

phys_copy(user_phys, vir2phys(&tp->tty_winsize) , (phys_bytes) size); 

/* SIGWINCH... */' 

case KIOCSMAP: 

/* Cargar nuevo mapa de teclas (sólo /dev/console). */ 
if (isconsole(tp)) r = kbd_loadmap(user_phys); 

case TIOCSFON: 

/* Cargar fuente en una tarjeta EGA o VGA (hs@hck.hr) */ 
if (isconsole(tp)) r = con_loadfont(user_phys); 


12154/* Se permite que estas funciones Posix fallen si no está 
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12155 * definido POSIXJOBCONTROL. 

12156 */ 

12157 case TIOCGPGRP: 

12158 case TIOCSPGRP: 

12159 default: 

12160 r = ENOTTV; 

12161 } 

12162 

12163 /* Enviar la respuesta. */ 

12164 tty_reply(TASK_REPLV, m_ptr.>m_source, m_ptr->PROC_NR, r); 

12165 } 


12168 /*============================================ 

12169 * do_open 

12170 ♦ ==== ==== ====== ==== ========= == 

12171 PRIVATE void do_open(tp, m_ptr) 

12172 register tty_t *tp; 

12173 message *m_ptr; /* apunto a mens. enviado a tarea */ 

12174 { 

12175 /* Se abrió 1 línea tty. Que sea la tty controladora del invocador si 0_N0CTTV 

12176 * está apagada y no es el dispositivo de bitácora. Se devuelve 1 

12177 * si la tty se hace la controladoraj si no, OK o un código de error. 

12178 */ 

12179 int r = OK; 

12180 

12181 if (m_ptr->TTV_LINE = LOGMINOR) { 

12182 /* El disp. de bitácora es un disp. de diagnóstico sólo de escritura. */ 

12183 if (m_ptr.>COUNT & R BIT) r = EACCES; 

12184 } else { 

12185 if (1 (m_ptr->COUNT & 0_N0CTTV)) { 

12186 tp->tty_pgrp = m_ptr->PROC_NR; 

12187 r= 1:; 

12188 } 

12189 tp->tty_openct++; 

12190 } 

12191 tty_reply(TASK_REPLV, m_ptr.>m_source, m_ptr.>PROC_NR, r); 

12192 } 


12195 /*================== === ====================== == ====== 

12196 * 

12197 *====== - ======================= = ===================== == 

12198 PRIVATE void do_close(tp, m_ptr) 

12199 register tty_t *tp; 

12200 message *m_ptr; /* apunto a mens. enviado a tarea */ 

12201 { 

12202 /* Se cerró 1 línea tty. Asear línea si es último cierre. */ 

12203 

12204 if (m_ptr->TTV_LINE 1= LOG MINOR && ,-tp.>tty_openct = 0) { 

12205 tp.>tty_pgrp = 0; 

12206 tty_icancel(tp); 

12207 (*tp.>tty_ocancel) (tp); 

12208 (*tp->tty_close) (tp); 

12209 tp.>tty_termios = termios_defaults; 

12210 tp->tty_winsize = winsize_defaults; 

12211 setattr(tp); 

12212 } 

12213 tty_reply(TASK_REPLV, m_ptr.>m_source, m_ptr->PROC_NR, OK)¡ 

12214 } 
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12217 /♦==== ======== = ======= = ===== = === 

12218 * do_cancel 

12219 * = = = ================== = ======== = === = == = ====== = = = = === = = = = == 

12220 PRIVATE void do_cancel(tp, m_ptr) 

12221 register tty_t *tp; 

12222 message *m_ptr; /* apunto a mensaje enviado a tarea */ 

12223 { 

12224 /* Se envió una señal a un proceso que está suspendido tratando de leer 

12225 * o escribir. Terminar inmediato lectura o escritura pendiente. 

12226 */ 

12227 

12228 int proc_nr; 

12229 int mode; 

12230 

12231 /* Revisar paráms. con cuidado, p/evitar cancelar dos veces. */ 

12232 proc_nr = m_ptr->PROC_NR; 

12233 mode = m_ptr->COUNT; 

12234 if ((mode & R_BIT) && tp->tty_inleñ != 0 && proc_nr = tp->tty_inproc) { 

12235 /* El proceso leía cuando se terminó. Asear entradas. */ 

12236 tty_icancel(tp); 

12237 tp->tty_inleft = tp->tty_incum = 0; 

12238 } 

12239 if ((mode & W_BIT) && tp->tty_outleft != 0 && proc_nr = tp->tty_outproc) { 

12240 /* El proceso escribía cuando se terminó. Asear salidas. */ 

12241 (*tp->tty_ocancel)(tp); 

12242 tp->tty_outleft = tp->tty_outcum = 0; 

12243 } 

12244 if (tp->tty_ioreq != 0 && proc_nr == tp->tty_ioproc) { 

12245 /* El proceso estaba esperando que la salida drenara. */ 

12246 tp->tty_ioreq = 0; 

12247 } 

12248 tp->tty_events = 1; 

12249 tty_reply(TASK_REPLY, m_ptr->m_source, proc_nr, EINTR); 

12250 } 


12254 * handle_events 

12255 * = = = = = = = === = = = = == = = = = = == === = = = = ==== = = = == = === = ==== = 

12256 PUBLIC void handle_events(tp) 

12257 tty_t *tp; /* TTY para detectar eventos. */ 

12258 { 

12259 /* Manejar cualesquier eventos pendientes en una TTY; por lo regular son interrupciones 

12260 * de dispositivos. 

12261 * 

12262 * Dos clases de eventos sobresalen: 

12263 * -se recibió 1 caro de la consola o línea RS232. 

12264 * -línea RS232 completó solicitud de escrito (p/un usuario). 

12265 * El manejador de ints. puede retardar el mens. de int. a discreción 

12266 * pino saturar la tarea TTY. Pueden sobreescribirse mensajes si las líneas 

12267 * son rápidas o hay competo entre diferentes líneas, entrada y salida, 

12268 * porque MINIX sólo tiene 1 buffer p/mensajes de int. (en proc.c). Esto 

12269 * se maneja revisando explícitamente cada línea para detectar entradas 

12270 * nuevas y salidas terminadas en cada interrupción. 

12271 */ 

12272 char *buf; 

12273 unsigned count; 

12274 
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12275 

12276 

12277 

12278 

12279 

12280 
12281 
12282 

12283 

12284 

12285 

12286 

12287 

12288 

12289 

12290 

12291 

12292 

12293 

12294 

12295 

12296 

12297 


do { 

tp->tty_events = Oj 

/* Leer entradas y procesarlas. */ 

(*tp->tty_devread)(tp); 

/* Procesar salidas y escribirlas. */ 

(*tp->tty_devwrite) (tp); 

/* ¿Espera ioctl algún evento? */ 
if (tp->tty_ioreq != 0) dev_ioctl(tp); 

} while (tp->tty_events); 

/* Transferir cargo de cola de entrada a proceso en espera. */ 
in_transfer(tp); 

/* Contestar si hay suficientes bytes disponibles. */ 
if (tp->tty_incum >= tp->tty_min && tp->tty_inleft > 0) { 

tty_reply(tp- > tty_inrep co de, tp->tty_incaller, tp->tty_inproc, 

tp^tty-incum); 

tp->tty_inleft = tp->tty_incum = 0; 

} 

} 


12300 /*====== = =========== == ======================= = ===== = 

12301 * in_transfer 

12302 * - - ====:========== = ========= = ==================== === 

12303 PRIVATE void in_transfer(tp) 

12304 register tty_t *tp;/* apunto a terminal de donde leer */ 

12305 { 

12306 /* Transí, bytes de cola de entrada a 1 proc. que lee de una terminal. */ 

12307 

12308 int ch; 

12309 int count; 

12310 phys_bytes buf_phys, user_base; 

12311 char buf[641, *bp; 

12312 


12313 /* ¿Algo que hacer? */ 

12314 if (tp->tty_inleft ==011 tp->tty_eotct < tp->tty_min) retum; 

12315 

12316 buf_phys = vir2phys(buf); 

12317 user_base = proc_vir2phys(proc_addr(tp->tty_inproc), 0); 

12318 bp = buf; 

12319 while (tp->tty_inleft > 0 && tp->tty_eotct > 0) { 

12320 ch = *tp->tty_intail; 

12321 

12322 if (1 (ch&IN_EOF)) { 

12323 /* Un carácter p/entregar al usuario. */ 

12324 *bp = ch «fe IN CHAR; 

12325 tp->tty_inlefi-"; 

12326 if(++bp = bufend(buf)) { 

12327 /* Buf. temp. lleno, copiar en espacio usuario. */ 

12328 phys_copy(buf_phys, user_base + tp->tty_in_vir, 

12329 (phys_bytes) buflen(buf)); 

12330 tp->tty_in_vir+= buflen(buf); 

12331 tp->tty_incum += buflen(buf); 

12332 bp = buf; 

12333 } 

12334 } 


*/ 
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12335 

12336 /* Quitar carácter de la cola de entrada. */ 

12337 if (++tp->tty_intail = bufend(tp->tty_inbuf)) 

12338 tp->tty_intail = tp->tty_inbuf; 

12339 tp->tty_incount—; 

12340 if (ch & IN_EOT) { 

12341 tp->tty_eotct—j 

12342 /* No leer después de salto-línea en modo canónico. */ 

12343 if (tp->tty_termios.c_lflag & ICANON) tp->tty_inleft = 0; 

12344 ¡ 

12345 } 

12346 

12347 if (bp > buf) { 

12348 /* Caracteres sobrantes en buffer. */ 

12349 count = bp -buf; 

12350 phys_copy(buf_phys, user_base + tp->tty_in_vir, (phys_bytes) count); 

12351 tp->tty_in_vir += count; 

12352 tp->tty_incum += count; 

12353 } 

12354 

12355 /* Usualmente contestar a lector, quizá aun si incum = 0 (EOF). */ 

12356 if (tp->tty_inleñ = 0) { 

12357 tty_reply(tp->tty_inrepcode, tp->tty_incaller, tp->tty_inproc, 

12358 tp->tty_incum); 

12359 tp->tty_inleft = tp->tty_incum = 0; 

12360 } 

12361 } 


12364 /*===================== 

12365 * in_process 

12366 * = = = === = ===== = = = = = === == === == = 


12367PUBLIC int in_process(tp, buf, count) 
12368register tty t *tp; 

12369char *buf; 

12370int count; 


/* terminal en la que llegó carácter */ 
/* buffer con caracteres de entrada */ 
/* núm. de caracteres de entrada */ 


12371 

12372 

12373 

12374 

12375 

12376 

12377 

12378 

12379 

12380 

12381 

12382 

12383 

12384 

12385 

12386 

12387 

12388 

12389 

12390 

12391 

12392 

12393 

12394 


{ 

/* Se acaban de teclear caracteres. Procesar, guardar y hacer eco. Devolver 
* el número de caracteres procesados. 


int ch, sig, ct; 

int timeset = FALSE; 

static unsigned char csize_mask[] = { OxlF, 0x3F, 0x7F, OxFF }; 

for (ct = Oj ct < countj ct++) { 

/* Tomar un carácter. */ 
ch = *buf++ & BYTE; 

/* ¿Reducir a siete bits? */ 

if (tp->tty_termios.c_iflag & ISTRIP) ch &= 0x7F; 

/* ¿Extensiones de entrada? */ 
if (tp->tty_termios.c_lflag & IEXTEN) { 

/* ¿Caro anterior fue de escape? */ 
if (tp->tty_escaped) { 

tp->tty_escaped = NOTESCAPED; 

ch 1= IN_ESC; /* proteger carácter */ 

} 
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12395 

12396 

12397 

12398 

12399 

12400 

12401 

12402 

12403 

12404 

12405 

12406 

12407 

12408 

12409 

12410 

12411 

12412 

12413 

12414 

12415 

12416 

12417 

12418 

12419 

12420 

12421 

12422 

12423 

12424 

12425 

12426 

12427 

12428 

12429 

12430 

12431 

12432 

12433 

12434 

12435 

12436 

12437 

12438 

12439 

12440 

12441 

12442 

12443 

12444 

12445 

12446 

12447 

12448 

12449 

12450 

12451 

12452 

12453 

12454 


/* ¿LNEXT (AV) p/escapar sigo carácter? */ 
if (ch == tp->tty_termios.c_cc[VLNEXT]) { 
tp->tty_escaped = ESCAPED; 
rawecho(tp, 'A'); 

rawecho(tp, ’\b'); 

continué; /* no guardar el escape */ 

} 

/* ¿REPRINT (AR) p/reimprimir cars. de eco? */ 
if (ch == tp->tty_termios.c_cc[VREPRINT]) { 
reprint(tp); 
continué; 

} 

} 

/* POSIXVDISABLE es valor de caro normal, mejor escaparlo. */ 
if (ch = POSIX VDISABLE) ch 1= IN_ESC; 

/* Convertir CR en LF, ignorar CR, o convertir LF en GR. */ 
if (ch = V) { 

if (tp->tty_termios.c_iflag & IGNCR) continué; 
if (tp->tty_termios.c_iflag & ICRNL) ch = Vi; 

} else 

if (ch = '\n') { 

if (tp->tty_termios.c_iflag & INLCR) ch = V ; 

} 


/* ¿Modo canónico? */ 
if (tp->tty_termios.c_lflag & ICANON) { 

/* Procesar borrado (del último carácter). */ 
if (ch == tp->tty_termios.c_cc[VERASE]) { 

(void) back_over(tp); 

if (! (tp->tty_termios.c_lflag & ECHOE)) { 

(void) echo(tp, ch); 

} 

continué; 

} 


/* Terminar procesamiento (quitar línea actual). */ 
if (ch == tp->tty_termios ,c_cc [VKILL]) { 
while (back_over(tp)) {} 
if (! (tp->tty_termios.c_lflag & ECHOE)) { 

(void) echo(tp, ch); 

if (tp->tty_termios.c_lflag & ECHOK) 
rawecho(tp, !\n'); 


} 

continué; 


/* EOF (AD) es fm-de-archivo, "salto de línea" invisible. */ 
if (ch == tp->tty_termios.c_cc[VEOF]) ch 1= IN EOT IIN EOF; 

/* La línea puede devolverse al usuario después de un LF. */ 
if (ch == V) ch 1 = IN EOT; 

/* Lo mismo con EOL, sea lo que sea. */ 

if (ch == tp->tty_termios.c_cc[VEOL]) ch 1= IN EOT; 
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12455 

12456 

12457 

12458 

12459 

12460 

12461 

12462 

12463 

12464 

12465 

12466 

12467 

12468 

12469 

12470 

12471 

12472 

12473 

12474 

12475 

12476 

12477 

12478 

12479 

12480 

12481 

12482 

12483 

12484 

12485 

12486 

12487 

12488 

12489 

12490 

12491 

12492 

12493 

12494 

12495 

12496 

12497 

12498 

12499 

12500 

12501 

12502 

12503 

12504 

12505 

12506 

12507 

12508 

12509 

12510 

12511 

12512 

12513 

12514 


/* ¿Control de entradas start/stop? */ 
if (tp->tty_termios.c_iflag & IXON) { 

/* Las salidas paran con STOP ( A S). */ 
if{ ch = tp->tty_termios.c_cc[VSTOP]) { 
tp->tty_inhibited = STOPPED; 
tp->tty_events = 1 ; 
continué; 

} 

/* Salidas reinician con START (’O) o cualq. caro si EXANY. */ 
t/(tp->tty_inhibited) { 

if (ch = tp->tty_termios.c_cc[VSTART] 

| | (tp->tty_termios.c_iflag & IXANY)) { 

tp->tty_inhibited = RUNNING; 
tp->tty_events = 1 ; 

if (ch = tp->tty_termios.c_cc[VSTART]) 


if (tp->tty_termios.c_lflag & ISIG) { 

/* Detectar caracteres INTR ('?) Y OUIT (’\). */ 
if (ch = tp->tty_termios.c_cc[VINTR] 

11 ch==tp->tty_termios.c_cc[VOUIT]) { 

sig = SIGINT; 

if {ch = tp->tty_termios.c_cc[VOUIT]) sig = SIGOUIT; 
sigchar(tp, sig); 

(void) echo(tp, ch); 


/* ¿Hay espacio en el buffer de entrada? */ 
if (tp->tty_incount = buflen(tp->tty_inbuf)) { 

/* No hay; desechar en modo canónico, guardar en modo crudo. */ 
//'(tp->tty_termios ,c_ 1 f 1 ag & ICANON) continué; 
break; 

} 

if (! (tp->tty_termios.c_lflag & ICANON)) { 

/* En modo crudo todos los cars. son "saltos de linea". */ 
ch |= IN EOT; 

/* ¿Poner en marcha un temporizador entre bytes? */ 
if (¡timeset && tp->tty_termios.c_cc[VMIN] > 0 

&& tp->tty_termios.c_cc[VTIME] > 0) { 
lock(); 

settimer(tp, TRUE); 

unlock(); 
timeset = TRUE; 

} 

} 


/* Realizar la intrincada función de hacer eco. */ 

if (tp->tty_termios.c_lflag & (ECHOIECHONL)) ch = echo(tp, ch); 
/* Guardar el carácter en la cola de entrada. */ 
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12515 *tp->tty_inhead++ = ch; 

12516 if (tp->tty_inhead == bufend(tp->tty_inbuf)) 

12517 tp->tty_inhead = tp->tty_inbuf; 

12518 tp->tty_inoount++; 

12519 if (ch & IN_EOT) tp->tty_eotct++; 

12520 

12521 /* Tratar de terminar entradas si la cola amenaza desbordarse. */ 

12522 if (tp->tty_incount = buflen(tp->tty_inbuf)) in_transfer(tp); 

12523 } 

12524 retumct; 

12525 } 

12528 /♦============================================= = ======= == 

12529* echo * 

12530 * ==== ==== ====== ==== === = === = =========== 

12531 PRIVATE int echo(tp, ch) 

12532 register tty_t *tp; /* Terminal para el eco */ 

12533 register int ch; /* apunto al carácter para eco */ 

12534 { 

12535 /* Hacer eco del carácter si el eco está activo. Algunos caracteres de control 
12536* hacen eco con su efecto normal, otros hacen eco como "AX", los caracteres 

12537 * normales aparecen normalmente. Se hace eco de EOF (AD), pero seguido 

12538 * de retrocesos. Devolver el carácter con la longitud del eco agregada 
12539* a sus atributos. 

12540 */ 

12541 int len, rp; 

12542 

12543 ch <&= -IN_LEN; 

12544 if (! (tp->tty_termios.c_lflag «fe ECHO)) { 

12545 if (ch = ('\n' I IN_EOT) <fe«fe (tp->tty_termios.c_lflag 

12546 & (ICANONIECHONL)) == (ICANONIECHONL)) 

12547 (*tp->tty_echo) (tp, '\n'); 

12548 retum(ch); 

12549 } 

12550 

12551 /* "Reprint" dice si otras salidas arruinaron la salida de eco. */ 

12552 rp = tp->tty_incount == 0 ? FALSE : tp->tty_reprint; 

12553 

12554 if ((ch & INCHAR) < ’ ’) { 

12555 switch (ch & (IN_ESCIIN_EOFIIN_EOTIIN_CHAR)) { 

12556 case ' \ t 

12557 len = 0; 

12558 do { 

12559 (*tp->tty_echo) (tp,,'); 

12560 len++; 

12561 } while (len < TAB_SIZE &<fe (tp->tty_position «fe TAB MASK) != 0); 

12562 break; 

12563 case' \ r' | IN_EOT: 

12564 case ’ \ n ’ | IN_EOT: 

12565 (*tp->tty_echo) (tp, ch «fe IN CHAR); 

12566 len = 0; 

12567 break; 

12568 default: 

12569 (*tp->tty_echo) (tp, 'A'); 

12570 (*tp->tty_echo) (tp, ’@’ + (ch «fe IN CHAR)); 

12571 len = 2; 

12572 } 

12573 } else 

12574 if ((ch «fe IN CHAR) = ’\177’) { 
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12575 /* Un DEL aparece como "’7". */ 

12576 (*tp->tty_echo) (tp, 

12577 (*tp->tty_echo) (tp, 7’); 

12578 len = 2; 

12579 } else { 

12580 (*tp->ty_echo) (tp, ch & INCHAR); 

12581 len = 1; 

12582 } 

12583 if (ch & IN_EOF) while (len > 0) { (*tp->tty_echo) (tp, '\b'); len-; } 

12584 

12585 tp->tty_reprint = rp; 

12586 return(ch I (len (( INLSHIFT)); 

12587 } 

12590 /♦==== === ===== ======= = ============ 

12591 * rawecho * 

12592 * = = = = = ======= = == = === = == = ==== = = = == == == = = = = == = = ==== ==== 

12593 PRIVATE void rawecho(tp, ch) 

12594 register tty_t *tp; 

12595 intch; 

12596 { 

12597 /* Eco sin interpretación si ECHO está encendido. */ 

12598 int rp = tp->tty_reprint; 

12599 if (tp->tty_termios.c_lflag & ECHO) (*tp->tty_echo) (tp, ch); 

12600 tp->tty_reprint = rp; 

12601 } 

12604 /*===== = = = = == = = = = ====== = = = = == === = = == = == == == = == = = = === == 

12605 * backover * 

12606 *============================-========================= == 

12607 PRIVATE int back_over(tp) 

12608 register tty_t *tp; 

12609 { 

12610 /* Retroceder al carácter anterior en la pantalla y borrarlo. */ 

12611 ul6_t *head; 

12612 int len; 

12613 

12614 if (tp->tty_incount = 0) retum(O); /* cola vacía */ 

12615 head = tp->tty_inhead; 

12616 if (head = tp->tty_inbuf) head = bufend(tp->tty_inbuf); 

12617 if (*-head & IN_EOT) retum(0); /* imposible borrar "saltos" */ 

12618 if (tp->tty_reprint) reprint(tp); /* reimprimir si arruinada */ 

12619 tp->tty_inhead = head; 

12620 tp->tty_incount—; 

12621 if (tp->tty_termios.c_lflag & ECHOE) { 

12622 len = (*head & IN_LEN) » IN LSHIFT; 

12623 while (len > 0) { 

12624 rawecho(tp,'\b'); 

12625 rawecho(tp,' '); 

12626 rawecho(tp, ’\b'); 

12627 len-; 

12628 } 

12629 } 

12630 retum(l); /* un carácter borrado */ 

12631 } 


12634, 












Archivo: src/kemel/tty.c 


693 


EL CÓDIGO FUENTE DE MINIX 

12635 * reprint * 

12636 * ■ . ■.. ■ .. ■. ■■ ===== == ========= = ;:■- == = == ================ == == = ==== = 

12637PRIVATE void reprint(tp) 

12638register tty_t *tp; /* apuntador a struct tty */ 

12639 { 

12640/* Restaurar el eco anterior a la pantalla si las salidas arruinaron las entradas 

12641 * del usuario o si se tecleó REPRINT (AR). 

12642 */ 

12643 int count; 

12644 ul6_t *head; 

12645 

12646 tp->tty_reprint = FALSE; 

12647 

12648 /* Encontrar último salto de línea en la entrada. */ 

12649 head = tp->tty_inhead; 

12650 count = tp->tty_incount; 

12651 while (count > 0) { 

12652 if (head = tp->tty_ínbuf) head = bufend(tp->tty_inbuf); 

12653 if (head[ -1] & IN EOT) break; 

12654 head-; 

12655 count-; 

12656 } 

12657 if (count = tp->tty_incount) retum; /* ninguna razón p/reimprimir */ 

12658 

12659 /* Mostrar REPRINT (AR) Y pasar a nueva línea. */ 

12660 (void) echo(tp, tp->tty_termios.c_cc[VREPRINT] I IN_ESC); 

12661 rawecho(tp,' Vr') ; 

12662 rawecho(tp,'\n'); 

12663 

12664 /* Reimprimir desde el último corte en adelante. */ 

12665 do { 

12666 if (head == bufend(tp->tty_inbuf)) head = tp->tty_inbuf; 

12667 *head = echo(tp, *head); 

12668 head++; 

12669 count++; 

12670 } while (count < tp->tty_incount); 

12671 } 

12674 /*============================================= = ========= 

12675* out_process * 

12676 * - - ========= = = = == == = === =============== === ======= = 

12677 PUBLIC void out_process(tp, bstart, bpos, bend, icount, ocount) 

12678 tty_t *tp; 

12679 char *bstart, *bpos, *bend; /* inic/pos/fin de buffer circular */ 

12680 int *icount; /* # cars entrada / cars entrada usados */ 

12681 int *ocount; /* máx. cars salida / cars salida usados */ 

12682 { 

12683 /* Procesar salidas en buffer circular. *icount es el núm. de bytes por procesar, 

12684* Y los bytes realmente procesados al regresar. *ocount es el espacio 
12685* disponible en entradas y el usado en salidas. (Naturalmente, *icount 
12686* < *ocount.) La posición de columna se actualiza módulo al tamaño 
12687* de TAB, porque realmente sólo la necesitamos para tabulaciones. 

12688 */ 

12689 

12690 int tablen; 

12691 int ict = *icount; 

12692 int oct = *ocount; 

12693 int pos = tp->tty_position; 

12694 



694 

12695 

12696 

12697 

12698 

12699 

12700 

12701 

12702 

12703 

12704 

12705 

12706 

12707 

12708 

12709 

12710 

12711 

12712 

12713 

12714 

12715 

12716 

12717 

12718 

12719 

12720 

12721 

12722 

12723 

12724 

12725 

12726 

12727 

12728 

12729 

12730 

12731 

12732 

12733 

12734 

12735 

12736 

12737 

12738 

12739 

12740 

12741 

12742 

12743 

12744 

12745 

12746 

12747 

12748 

12749 

12750 

12751 

12752 

12753 

12754 
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while (ict > 0) { 

switch (*bpos) { 


= (OPOSTIONLCR)) { 


if ((tp->tty_termios.c_oflag & (OPOSTIONLCR)) 

/* Convertir LF en CR+LF si hay espacio. 

* Se reescribe el sigo carácter del buffer, 

* así que nos detenemos aquí. 


if (oct >= 2) { 

*bpos =' \ r 

if (++bpos — bend) bpos = bstart; 

*bpos =' \ n 
pos = 0; 

oct -= 2;’ 

} 

goto out_done; /* no hay espacio o buffer cambió */ 

} k 

/* Mejor estimación de la long. de tabulación. */ 
tablen = TA8_SIZE -(pos & TABMASK); 

if ((tp->tty_termios.c_oflag & (OPOSTIXTABS)) 

/* Las tabulaciones deben expandirse. */ 
if (oct >= tablen) { 

pos += tablen; 


= (OPOSTIXTABS)) { 


/* Las tabulaciones 
pos += tablen; 

default: 

/* Suponer que los demás 
pos++; 

} 

if (++bpos = bend) bpos = bstart; 


it_done: 

tp->tty_position = pos & TAB_MASK; 


*bpos =''; 

if (++bpos == bend) bpos = bstart; 
} while (—tablen 1= 0); 

} 

goto out_done; 

envían directamente a la salida. */ 



EL CÓDIGO FUENTE DE MINIX Archivo: src/kemel/tty.c 695 

12755 *icount-= ict; /* [io]ct son núms. de cars. no usados */ 

12756 *ocount -= oct; /* *[io]count son núms. de cars. usados */ 

12757 } 

12760 /♦==== === ===== == = ==== = ===== = === 

12761 * dev_ioctl * 

12762 *============================= == ===== = ========= == ======= = 

12763 PRIVATE void dev_ioctl(tp) 

12764 tty_t *tp; 

12765 { 

12766 /* TCSETSW, TCSETSF y TCDRAIN de ioctl esperan que las salidas 

12767 * terminen para asegurarse que un cambio de atrib. no afecte el procesam. 

12768 * de salidas actuales. Ya terminadas, el ioctl se ejecuta como en do_ioctl(). 

12769 */ 

12770 phys_bytes user_phys; 

12771 

12772 if (tp->tty_outleft > 0) retum; /* no han terminado las salidas */ 

12773 

12774 if(tp->tty_ioreq != TCDRAIN) { 

12775 if (tp->tty_ioreq = TCSETSF) tty_icancel(tp); 

12776 user_phys = proc_vir2phys(proc_addr(tp->tty_ioproc), tp->tty_iovir); 

12777 phys_copy(user_phys, vir2phys(&tp->tty_termios), 

12778 (phys_bytes) sizeof(tp->tty_termios)); 

12779 setattr(tp); 

12780 } 

12781 tp->tty_ioreq = 0; 

12782 tty_reply(REVIVE, tp->tty_iocaller, tp->tty_ioproc, OK); 

12783 } 


12787 * setattr 

12788 *== = = = = ===== = ===== = == == = = ===== = ====== == ====== ==: 

12789 PRIVATE void setattr(tp) 

12790 tty_t *tp; 

12791 { 

12792 /* Aplicar nuevos atrib. de línea (crudo/canónico, velo de línea, etc.) */ 

12793 ul6_t *inp; 

12794 intcount; 

12795 

12796 if (! (tp->tty_termios.c_lflag & ICANON)) { 

12797 /* Modo crudoj agregar "salto de línea" a cada carácter de cola de entrada. 

12798 * No se define qué sucede con la cola sí ICANON se apaga; los procs. 

12799 * deben usar TCSAFLUSH para vaciar la cola. Sin embargo, lo correcto 

12800 * es guardar la cola para preservar el tecleo adelantado cuando un proceso 

12801 * usa TCSANOW para cambiar a modo crudo. 

12802 */ 

12803 count = tp->tty_eotct = tp->tty_incount; 

12804 inp = tp->tty_intail; 

12805 while (count > 0) { 

12806 *inp 1= INEOT; 

12807 if (++inp == bufend(tp->tty_inbuf)) inp = tp->tty_inbuf; 

12808 - -count; 

12809 } 

12810 } 

12811 

12812 /* Examinar MIN y TIME. */ 

12813 lock(); 

12814 settimer(tp, FALSE); 
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12815 unlock(); 

12816 if (tp->tty_termios.c_lflag & ICANON) { 

12817 /* No MESÍ ni TIME en modo canónico. */ 

12818 tp->tty_min= 1; 

12819 } else { 

12820 /* En modo crudo, MIN es núm. de caracteres deseado, y TIME cuánto 

12821 * esperarlos. Con excepciones interesantes si cualquiera es cero. 

12822 */ 

12823 tp->tty_min = tp->tty_termios.c_cc[VMIN]; 

12824 if (tp->tty_min = 0 && tp->tty_termios.c_cc[VTIME] > 0) 

12825 tp->tty_min = 1; 

12826 } 

12827 

12828 if (!(tp->tty_termios.c_iflag & IXON)) { 

12829 /* Sin control de salidas start/stop, así que no dejar salidas inhibidas. */ 

12830 tp->tty_inhibited = RUNNING; 

12831 tp->tty_events = 1; 

12832 } 

12833 

12834 /* Poner en cero la velocidad de salida cuelga el teléfono. */ 

12835 if (tp->tty_termios.c_ospeed = 80) sigchar(tp, SIGHUP); 

12836’ 

12837 /* Fijar nueva velo de línea, tamaño car., etc. en nivel de dispositivo. */ 

12838 (*tp->tty_ioctl) (tp); 

12839 } 


12842 /’ 

12843 * 

12844 * 

12845 

12846 

12847 

12848 

12849 

12850 

12851 

12852 

12853 

12854 

12855 

12856 

12857 

12858 

12859 

12860 


tty_reply 


PU8LIC void tty_reply(code, replyee, proc_nr, status) 

intcode; /* TASK REPLY o REVIVE */ 

int replyee; /* dir. de destino p/respuesta */ 
int proc_nr; /* ¿a quién debe dirigirse la resp.? 
int status; /* código de respuesta */ 

{ 

/* Enviar respuesta al proceso que quería leer o escribir datos. */ 

message tty_mess; 

tty_mess.m_type = code; 
ttymess.REPPROCNR = procnr; 
ttymess.REPSTATUS = status; 

if ((status = send(replyee, &tty_mess)) != OK) 

panic("tty_reply failed, status\n", status); 


} 


*/ 


12863/*==========================c============ = ==================* 

12864 * sigchar * 

12865 *== = = = ■ ■ = =====:= = ========= = -■ ======================%==============*/ 

12866 PU8LIC void sigchar(tp, sig) 

12867 register tty_t *tp; 

12868 int sig; /* SIGINT, SIGQUIT, SIGKILL o SIGHUP */ 

12869 { 

12870 /* Procesar 1 caro SIGINT, SIGQUIT o SIGKILL del teclado o SIGHUP 

12871 * de cierre de tty, "stty 0" o cuando se cuelga realmente una línea RS-232. 

12872 * MM enviará la señal al grupo de procesos (INT, QUIT), a todos los procesos 

12873 * (KILL) o al líder de sesión (HUP). 

12874 */ 
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12875 

12876 if (tp->tty_pgrp 1= 0) cause_sig(tp->tty_pgrp, sig) 

12877 ’ 

12878 if (1 (tp->tty_termios.c_lflag & NOFLSH)) 

12879 tp->tty_incount = tp->tty_eotct = 0; 

12880 tp->tty_intail = tp->tty_inhead; 

12881 {*tp->tty_ocancel) (tp)j 

12882 tp->tty_inhibited = RUNNING; 

12883 tp->tty_events = 1; 

12884 } 

12885 } 

12888 /*===== == = == = = ===== 

12889 * tty_icancel 

12890 ♦ ==== ==== ====== ==== ======= ==== === 

12891 PRIVATE void tty_icancel(tp) 

12892register tty_t *tp; 

12893 { 

12894 /* Desechar todas las entradas pendientes, buffer tty o dispositivo. */ 

12895 

12896 tp->tty_incount = tp->tty_eotct = 0; 

12897 tp->tty_intail = tp->tty_inhead; 

12898 (*tp->tty_icancel) (tp); 

12899 } 

12902 /*====== == = = ======== = ======= = = = = = == == === 

12903 * ttyjnit 

12904 * ==== === = ==== ====== == = = = = == = === ==== 

12905 PRIVATE void tty_init(tp) 

12906 tty_t *tp; /* Línea TTY por inicializar. */ 

12907 { 

12908 /* Me. estructura tty e invocar rutinas de Me. de dispositivo. */ 

12909 

12910 tp->tty_intail = tp->tty_inhead = tp->tty_inbuf; 

12911 tp->tty_min = 1; 

12912 tp->tty_termios = termios_defaultS; 

12913 tp->tty_icancel = tp->tty_ocancel = tp->tty_ioctl = tp->tty_close = 

12914 tty_devnop; 

12915 if (tp < tty_addr(NR_CONS)) { 

12916 scr_init(tp); 

12917 } else 

12918 if (tp < tty_addr(NR_CONS+NR_RS_LINES)) { 

12919 rs_init(tp); 

12920 } else { 

12921 pty_Mt(tp); 

12922 } 

12923 } 

12926 /*===== === ====== == = = = == ====== === = 

12927* tty_wakeup 

12928 * = = = = == === = = = === = = ==== = = = = = = = = = = = = === = = = = == === 

12929 PUBLIC void tty_wakeup(now) 

12930 clock_tnow; /* tiempo actual */ 

12931 { 

12932 /* Despertar TTY si algo interesante está sucediendo en una de las líneas 

12933 * de terminal, como la llegada de un carácter por una línea RS232, la pulsación 

12934 * de una tecla o la expiración de un temporiz. en una línea por TIME. 


{ 

/* matar entradas anteriores */ 

/* matar todas las salidas */ 


*/ 


*/ 


*/ 












698 Archivo: src/kemel/tty.c EL CÓDIGO FUENTE DE MINI 

12935 */ 

12936 tty_t *tp; 

12937 

12938 /* Buscar en timerlist temporiz. expirados y calcular sigo plazo vencido. */ 

12939 tty timeout = TIMENEVER; 

12940 while ((tp = tty_timelist) != NULL) { 


12941 if (tp->tty_time > now) { 

12942 tty_timeout = tp->tty_time; /* sigue este temporizador */ 

12943 break; 

12944 } 

12945 tp->tty_min = 0; /* forzar lectura con éxito */ 

12946 tp->tty_events = 1; 

12947 tty_timelist = tp->tty_timenext; 

12948 } 

12949 

12950 /* Avisar a TTY que algo está sucediendo. */ 

12951 interrupt(TTY); 

12952 } 

12955 /*========================================= == ==============* 

12956 * settimer * 

12957 *===============================================================*/ 

12958 PRIVATE void settimer(tp, on) 

12959 tty_t *tp; /* línea para poner o quitar un temporiz. */ 

12960 int on; /* poner temporiz. si true, si no, quitar */ 

12961 { 

12962 /* Poner o quitar un temporiz. según TIME. Esta tunco es sensible a ints. a cau 


12963 * de tty_wakeup(), así que debe invocarse desde dentro de lock()/unlock(). 

12964 V 

12965 tty_t **ptp; 

12966 

12967 1 * Sacar tp de timerlist si está presente. *1 

12968 for (ptp = &tty_timelist; *ptp != NULL; ptp = &(*ptp)->tty_timenext) { 

12969 if(tp = *ptp){ 

12970 *ptp = tp->tty_timenext; /* sacar tp de la lista */ 

12971 break; 

12972 } 

12973 } 

12974 if (Ion) retum; /* basta con quitarlo */ 

12975 

12976 /* El plazo vence TIME decisegundos a partir de ahora. */ 

12977 tp->tty_time = get_uptime() + tp->tty_termios.c_cc[VTIME] * (HZ/10); 

12978 

12979 /* Encontrar un nuevo lugar en la lista. */ 

12980 for (ptp = &tty_timelist; *ptp != NULL; ptp = &(*ptp) ->tty_timenext) { 

12981 if (tp->tty_time <= (*ptp) ->tty_time) break; 

12982 } 

12983 tp->tty_timenext = *ptp; 

12984 *ptp = tp; 

12985 if (tp->tty_time < tty_timeout) tty_timeout = tp->tty_time; 

12986 } 

12989 /*============================== 

12990 * tty_devnop 

12991 *== 

12992 

12993 

12994 { 



PUBLIC void tty_devnop(tp) 
tty_t *tp; 
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12995 /* Algunas funes, no tienen que implementarse en nivel de dispositivo. */ 

12996 } 
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13000 

/* Controlador del teclado para PC 3 

^ AT. 


13001 

* 



13002 

* Modificado por Marcus Hampel 

(04/02/1994) 

13003 

* - Mapas de teclas cargables 



13004 

*/ 



13005 




13006 

#include "kernel.h" 



13007 

ffinclude <termios.h> 



13008 

#include <signal.h> 



13009 

#include <unistd.h> 



13010 

#include <minix/callnr.h> 



13011 

#include <minix/com.h> 



13012 

#include <minix/keymap.h> 



13013 

#include "tty.h" 



13014 

#include "keymaps/us-std.src" 



13015 




13016 

/* Teclado estándar y AT. (PS/2 MCA in 

íplica AT siempre.) */ 

13017 

#define KEYBD 

0x60 /* 

puerto de E/S p/datos del teclado */ 

13018 




13019 

/* Teclado AT. */ 



13020 

#define KB COMMAND 

0x64 /* 

puerto de E/S p/comandos en AT */ 

13021 

#define KB GATE A20 

0x02 /* 

bit en puerto salida p/habil. línea A20 */ 

13022 


#define KB PULSE OUTPUT OxFO /* base p/comandos p/pulsar puerto 

salida */ 




13023 

#define KB RESET 

0x01 /* 

bit en puerto salida p/restab. CPU */ 

13024 

#define KB STATUS 

0x64 /* 

puerto de E/S p/situación en AT */ 

13025 

#defme KB ACK 

OxFA /* 

respuesta ack del teclado */ 

13026 

#define KB BUSY 

0x02 /* 

bit de situac. 1 si puerto KEYBD listo */ 

13027 

#define LED CODE 

OxED /* 

comando a teclado p/activar LEDs */ 

13028 



#define MAX KB ACK RETRIES 0x1000/* máx. veces esperar 

acuse de teclado */ 



13029 



#define MAX KB BUSY RETRIES 0x1000 /* máx. ciclos 

mientras teclado ocupado */ 



13030 

#define KBIT 

0x80 /* 

bit p/acuse de cars. al teclado */ 

13031 




13032 

/* Diversos. */ 



13033 

#define ESC SCAN 

1 /* 

tecla p/rearranque si hay pánico */ 

13034 

#define SLASH SCAN 

53 /* 

p/reconocer diagonal numérica */ 

13035 

#define HOME SCAN 

71 /* 

la. tecla de subteclado num. */ 

13036 

#define DEL SCAN 

83 /* 

DEL p/usar en rearranque CTRL-ALT-DEL */ 

13037 

#define CONSOLE 

0 /* 

número de línea p/consola */ 

13038 

#define MEMCHECK ADR 

0x472 /* 

dir. p/detener verif. memo en rearranque */ 

13039 


#define MEMCHECK MAG 0x1234 /* núm. mágico p/detener verif. de 

memo */ 




13040 




13041 

#define kb addr() 

(&kb lines[0]) /* sólo hay un teclado */ 

13042 

#define KB IN BYTES 

32 /* 

tamaño de buffer entrada de teclado */ 

13043 




13044 


PRIVATE int altl; /* estado de tecla alt izquierda */ 

13045 


PRIVATE int alt2; /* estado de tecla alt derecha */ 

13046 


PRIVATE int capslock; /* estado de tecla Bloq Mayús */ 

13047 

PRIVATE int esc; 

/* ¿Código 

0 de escape detectado? */ 

13048 

PRIVATE int control; 

/* estado de tecla de control */ 

13049 

PRIVATE int caps off; 

/* 1 = pos 

. normal, 0 = oprimida */ 
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13050 

13051 

13052 

13053 

13054 

13055 

13056 

13057 

13058 

13059 

13060 

13061 

13062 

13063 

13064 

13065 

13066 

13067 

13068 

13069 

13070 

13071 

13072 

13073 

13074 

13075 

13076 

13077 

13078 

13079 
13080, 

13081 

13082 

13083 

13084 

13085 

13086 

13087 
13088, 

13089 

13090 

13091 

13092 

13093 

13094 

13095 

13096 

13097 

13098 

13099 

13100 

13101 

13102 

13103 

13104 

13105 

13106 

13107 

13108 

13109 
13057 
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PRIVATE int numlock; /* estado de tecla Bloq Núm */ 
PRIVATE int num_off; /* 1 = pos. normal, 0 = oprimida */ 
PRIVATE int slock; /* estado de tecla Bloq Despl */ 
PRIVATE int slock_off; /* 1 = pos. normal, 0 = oprimida */ 
PRIVATE int shift; /* estado de tecla shift */ 


PRIVATE char numpad_map[ ] = 

{ ' H ', ’Y’, ’A’, r 


, ’D’, ’C’, ’V, ’ ‘U’, ‘G’, ‘S’, ‘T% 


/* Estructura de teclado, ui 
struct kb_s { 
char *ihead; 
char *itail; 
int icount; 

char ibuf[KB_IN_BYTES]; 

}; 


PRIVATE struct kb_s kb_lines[NR_CDNS]; 


/* sigo lugar libre en buffer entrada */ 
/* cód. detección p/devolver a TTY */ 
/* núm. de códigos en buffer */ 

/* buffer de entrada */ 


FORWARD _PROTOTYPE( i 
FORWARD _PROTOTYPE( i 
FORWARD _PROTOTYPE( i 
FORWARD _PROTOTYPE( i 


ít kb_ack, (void)); 
ít kb_wait, (void)); 
ít func_key, (int scode)); 
i_keyboard, (void)); 


FORWARD _PROTOTYPE( unsigned make break, (int scode)); 
FORWARD _PROTOTYPE( void set leds, (void)); 

FORWARD _PROTOTYPE( int kbd_hw_int, (int irq) ); 
FORWARD _PROTOTYPE( void kb_read, (strnct tty *tp) ); 
FORWARD _PROTOTYPE( unsigned map key, (int scode)); 


/* Transformar código de detección a cód. ASCII ignorando modificadores. */ 
#define map_key0( scode); 

((unsigned) keymap[(scode) * MAP_COLS]) 


/* Transformar un código de detección en código ASCII. */ 

int caps, column; 
ul6_t *keyrow; 

if (scode = SLASH_SCAN && esc) retum/* no transí, diage 
keyrow = &keymap[scode * MAP COLS]; 
caps = shift; 

if (numlock && HOME SCAN <= scode && scode <= DEL SCAN) caps = IcapS; 
if (capslock && (keyrow[0] & HASCAPS)) caps = ¡caps; 

if (altl | | alt2) { 

column = 2; 

if (control 11 alt2) column = 3; /* Ctrl + Altl = Alt2 */ 
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13110 if (caps) column = 4; 

13111 } else { 

13112 column = 0; 

13113 if (caps) column = 1; 

13114 if (control) column = 5; 

13115 } 

13116 retum keyrow[column] & -HASCAPS; 

13117 } 

131207*================================================================* 

13121 * kbd_hw_int * 

13122 *=================================================================*; 

13123 PRIVATE int kbd_hw_int(irq) 

13124int irq; 

13125 { 

13126 7 * Ocurrió una interrupción de teclado. Procesarla. *7 

13127 

13128 intcode; 

13129 unsigned km; 

13130 register struct kb_s *kb; 

13131 

13132 7 * Obtener el carácter del hardware del teclado y acusar recibo. *7 

13133 code = scan_keyboard(); 

13134 

13135 7* El teclado IBM interrumpe 2 veces por tecla, una al oprimirse, 

13136 * una al soltarse. Filtrar la segunda, ignorando todas las teclas menos las tipo 

13137 * shift. Las teclas tipo shift 29, 42, 54, 56, 58 Y 69 se procesan normalmente. 

13138 *7 

13139 

13140 if (code & 0200) { 

13141 7*Se soltó una tecla (bit alto encendido). *7 

13142 km = map_key0(code & 0177); 

13143 if (km != CTRL && km != SHIFT && km != ALT && km != CALOCK 

13144 && km != NLOCK && km != SLOCK && km != EXTKEY) 

13145 retum 1; 

13146 } 

13147 

13148 7 * Guardar carácter en memoria para que la tarea pueda usa;-iO después. *7 

13149 kb = kb_addr(); 

13150 if (kb->icount < KBINBYTES) { 

13151 *kb.>ihead++ = code; 

13152 if (kb->ihead = kb->ibuf + KB IN BYTES) kb->ihead = kb->ibuf; 

13153 kb->icount++; 

13154 tty_table[current].tty_events = 1; 

13155 force_timeout(); 

13156 } 

13157 7 * Si no cabe -desecharlo. *7 

13158 retum 1; 7 * Rehabilitar interrupción de teclado *7 

13159 } 

131627*================================================================* 

13163* kb_read * 

13164 *=================================================================*7 

13165 PRIVATE void kb_read(tp) 

13166 tty_t *tp; 

13167 { 

13168 7 * Procesar caracteres del buffer circular del teclado. *7 

13169 
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13170 

struct kb s *kb; 


13171 

char buf(3]; 



13172 

int scode; 



13173 

unsigned ch; 



13174 




13175 

kb = kb addr(); 


13176 

tp = 

= &tty table[current]; /* siempre usar c 

onsola actual */ 

13177 




13178 

while (kb->icount > 0) { 


13179 


scode = *kb->itail++; /* tomar 

un cód. detec. de tecla */ 

13180 

if (kb-: 

>itail == kb->ibuf + KB IN BYTES) kb->itail = kb- 

>ibuf; 

13181 

lock(); 


13182 

kb->icount—; 


13183 

Ul 

tilock(); 


13184 




13185 

/* Se i 

isan teclas de función para vaciados de depuración. */ 


13186 

if(fun 

c key(scode)) continué; 


13187 




13188 

/* Rea 

lizar procesamiento make/break. */ 


13189 

ch = rr 

íake break(scode); 


13190 




13191 

if (ch ■ 

<= OxFF) { 


13192 


/* Un carácter normal. */ 


13193 


buf[0] = ch; 


13194 


(void) in_process(tp, buf, 1); 


13195 

} else 



13196 

if (HOME <= ch && ch <= INSRT) { 


13197 


/* Secuencia de escape ASCII generada por subteclado num. */ 

13198 


buf[0] = ESC; 


13199 


buf[l] = 


13200 


buf[2] = numpad map[ch -HOME]; 


13201 


(void) in_process(tp, buf, 3); 


13202 

} else 



13203 

if (ch : 

= ALEFT) { 


13204 


/* Escoger la consola de núm. más bajo como actr 

tal. */ 

13205 


select cons01e(current-l)j 


13206 

} else 



13207 

if (ch : 

== ARIGHT) { 


13208 


/* Escoger la consola de núm. más alto como actúa 

1. */ 

13209 


select conSole(current+1); 


13210 

} else 



13211 

if (AF 

1 <= ch && ch <= AF12) { 


13212 


/* Alt-Fl es consola, Alt-F2 es ttycl, etc. */ 


13213 


select console(ch-AF1); 


13214 

} 



13215 

} 



13216 

} 



13219/" 
13220 * 


make_break 

* 

13222 

PRIVATE uní 

úgned make break(scode) 


13223 

int scode; 

/* cód. det. de tecla oprimida o 

soltada */ 

13224 

{ 



13225 

/* Esta rutina 

puede manejar teclados que sólo interrumpen cuando 


13226 

* se oprimen 

teclas, y también los que interrumpen al presionar y al soltar. 

13227 

* Por eficient 

;ia, la rutina de int. elimina casi todas las liberaciones 

de tecla. 

13228 

*/ 



13229 i 

nt ch, make; 









EL CÓDIGO FUENTE DE MINIX Archivo: src/kemel/keyboard.c 


13230 

13231 

13232 

13233 

13234 

13235 

13236 

13237 

13238 

13239 

13240 

13241 

13242 

13243 

13244 

13245 

13246 

13247 

13248 

13249 

13250 

13251 

13252 

13253 

13254 

13255 

13256 

13257 

13258 

13259 

13260 

13261 

13262 

13263 

13264 

13265 

13266 

13267 

13268 

13269 

13270 

13271 

13272 

13273 

13274 

13275 

13276 

13277 

13278 

13279 

13280 

13281 

13282 

13283 

13284 

13285 

13286 

13287 

13288 

13289 


static int CADcount = 0; 

/* Detectar CTRL-ALT-DEL y, si se encuentra, detener la computadora. 

* Sería mejor hacer esto en keyboard() en caso de que tty esté colgada, 

* excepto que control y alt se establecen en el código de alto nivel. 

*/ 

if (control && (altl 11 alt2) && scode = DEL SCAN) 

{ 

if (++CAD_count == 3) wreboot(RBTHALT); 
cause_sig(INIT_PROC_NR, SIGABRT); 
retum -1; 

} 

/* El bit de orden alto se enciende al soltar una tecla. */ 
make = (scode & 0200 ? 0 : 1); 

ch = map_key(scode & 0177); 

switch (ch) { 

case CTRL: 

control = make; 
ch = -1; 

case SHIFT: 

shift = make; 
ch = -1; 

case ALT: 

if(make) { 

if (esc) alt2 = 1; else altl = 1; 

} else { 

altl = alt2 = 0; 

} 

ch = -1; 

case CALOCK: 

if (make && capsoff) { 

capslock = 1 -capslock; 
set_leds(); 

} 

capsoff = 1 -make; 
ch = -1; 

caseNLOCK: 

if (make && num_off) { 

numlock = 1 -numlock. 
set_leds0; 


/* 0 = soltar, 1 = oprimir */ 

/* correspondencia con ASCII */ 


ch = -1; 


case SLOCK: 

if (make & SloCkOff) { 
slock = 1 -slock; 
set_ledsO; 


} 

sloCkOff= 1 -make; 
ch = -1; 

case EXTKEY: 
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13290 esc = 1; 

13291 retum(-l); 

13292 default: 

13293 if (Imake) ch =-1; 

13294 } 

13295 esc = 0; 

13296 retum(ch)' 

13297 } 

13300 /*===== === ====== === === == = ====== = === = 

13301 * setjeds * 

13302 *== = ============= = === = == = ==== = = = == = = = ==== = === = === = = == = = = = == = === == 

13303 PRIVATE void set_leds() 

13304 { 

13305 /* Activar LEOs en teclas Bloq Mayús y Bloq Num. */ 

13306 

13307 unsigned leds; 

13308 

13309 if (!pc_at) retum; /* PC/XT no tiene LEOs */ 

13310 

13311 /* codificar bits de LEO */ 

13312 leds = (slock « 0) I (numlock « 1) I (capslock « 2); 

13313 

13314 kb_wait(); /* esperar que el buffer esté vacío */ 

13315 out_byte(KEYBO, LEO.COOE); /* preparar teclados p/aceptar valores LEO */ 

13316 kb_ack(); /* esperar respuesta de acuse */ 

13317 

13318 kb_wait(); /* esperar que el buffer esté vacío */ 

13319 out byte (KEYBO, leds); /* dar al teclado valores LEO */ 

13320 kb_ack(); /* esperar respuesta de acuse */ 

13321 } 

13324 /*==== ==== == === == === === == == ====== = === = 

13325 * kb_wait * 

13326 * = = = = = = = ===== = = = = == = = == = ==== = = = == = = = = = ======= = ==== = = = == = === = 

13327 PRIVATE int kb_wait() 

13328 { 

13329 /* Esperar que el controlador esté listo; devolver 0 si vence el plazo. */ 

13330 

13331 int retries; 

13332 

13333 retries = MAXKBBUSYRETRIES + 1; 

13334 while (-retries 1= 0 && inby te (KBSTATUS) & KBBUSY) 

13335; /* esperar que no esté ocupado */ 

13336 retum(retries); /* no 0 si está listo */ 

13337 } 

13340 /*== == ======== = ====== 

13341 * 

13342 *======= == ===== = ====== 

13343 PRIVATE int kb_ack() 

13344 { 

13345 /* Esperar que tecl. acuse rec. últ 

13346 

13347 int retries; 

13348 

13349 retries = MAX KB ACK RETRIES 




. comando; devolver 0 si vence plazo. */ 
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13350 while (-retries 1= 0 && in_byte(KEYBD) != KBACK) 

13351 ; /* esperar acuse */ 

13352 retum(retries); /* no 0 si se recibió acuse */ 

13353 } 

13356 /*===== === ====== == = == = == = == = === = 

13357 * kbinit 

13358 *== = === = ===== = == = ====== = ===== = == == == = == === ==== = == = = 

13359 PUBLIC void kb_init(tp) 

13360 tty t *tp; 

13361 { 

13362 /* Inicializar el controlador en software del teclado. */ 

13363 

13364 register struct kb_s *kb; 

13365 

13366 /* Función de entrada. */ 

13367 tp->ttY_devread = kb_read; 

13368 

13369 kb = kb_addr(); 

13370 

13371 /* Preparar cola de entrada. */ 

13372 kb->ihead = kb->itail = kb->ibuf; 

13373 

13374 /* Establecer valores iniciales. */ 

13375 caps_off=l; 

13376 numoff = 1; 

13377 sloCkOff = 1; 

13378 esc = 0; 

13379 

13380 set_leds(); /* apagar led de Bloq Num */ 

13381 

13382 scan_keyboard(); /* detener bloqueo de digit. remanente */ 

13383 

13384 put_irq_handler(KEYBOARD_IRO, kbd_hw_int); /* estab. manejador ints. */ 

13385 enable_irq(KEYBOARD_IRO)j /* todo inicializado: no hay peligro*/ 

13386 } 

13389 /*===== === ====== == = = = == = == = === = 

13390 * kbd_loadmap 

13391 *==== = ========== = === = == = ======== == == = == ==== ====== = = 

13392 PUBLIC int kbd_loadmap(user_Phys) 

13393 phy s_bytes user_phy s; 

13394 { 

13395/* Cargar un nuevo mapa de teclas. */ 

13396 

13397 Phys_copy(user_phys, vir2phys(keymap), (phys_bytes) sizeOf(keymap)); 

13398 return(OK); 

13399 } 

13402 /*================= == ================= = ====== == 

13403* func_key 

13404 *====================== = = = == ^ = = ======= = ===== === 

13405 PRIVATE int func_key(scode) 

13406 int scode; /* cód. de detección de tecla de función */ 

13407 { 

13408 /* Este procedimiento atrapa teclas de tunco p/fínes de depuro y control. */ 

13409 
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unsigned code; 

code = map_keyO(scode); /* 10. ignorar modificadores */ 

if (code < F1 11 code > F12) retum(FALSE); /* no nos toca */ 

switch (map_key(scode)) { /* incluir modificadores */ 

case F1: p_dmp(); break; /* imprimir tabla de procesos */ 

caseF2: map_dmp(); break; /* imprimir mapa de memoria */ 

caseF3: toggle_scroll(); break; /* despl. pant. por har. vs. sof. */ 

case CF7: sigchar(&tty_table[CONSOLE], SIGQUIT); break; 

case CF8: sigchar(&tty_table[CONSOLE], SIGINT); break; 

case CF9: sigchar(&tty_table[CONSOLE], SIGKILL)j break; 

default: retum(FALSE); 

} 

retum(TRUE); 

} 


13429 /*===== = = = = == = = = = = = = == = = = = = == === == == = = = = = === === 

13430* scan_keyboard 

13431 * = = == = = === = = = = == = = = = = == === = = = = === == = ====== = = = ==== 

13432 PRIVATE int scan_keyboard() 

13433 { 

13434 /* Obtener el carácter del hardware de teclado y acusar recibo. */ 

13435 

13436 intcodej 

13437 int val; 

13438 

13439 code = in byte(KEYBD); /* obt. cód. det. de tecla oprimida */ 

13440 val = in_byte(PORT_B)j /* strobe al teclado p/ack el caro */ 

13441 out_byte (PORT_B, val IKBIT); /* subir estrobosc. el bit */ 

13442 out byte (PORTB, val)j /* bajar estrobosc. el bit */ 

13443 retumcode; 

13444 } 

13447 /*================== = ================= = ======= == 

13448 * wreboot 

13449 * = = === ===== = ===== = = === ===== = = = = = = = = = = ==== ==== 

13450 PUBLIC void wreboot(how) 

13451 inthow; /* 0 = alto, 1 = rearranque, 2 = pánico, ...*/ 

13452 { 

13453 /* Esperar digitaciones para imprimir info de depuración y rearrancar. */ 

13454 

13455 int quiet, code; 

13456 static ul 6_t magic = MEMCHECK MAG; 

13457 struct tasktab *ttp; 

13458 

13459 /* Enmascarar todas las interrupciones. */ 

13460 out_byte (INT CTLMASK, -0); 

13461 

13462 /* Decir a varias tareas que se detengan. */ 

13463 cons_stop(); 

13464 floppy_stop(); 

13465 clock_stop(); 

13466 

13467 if (how = RBT HALT) { 

13468 printf(" System Halted\n"); 

13469 if (!mon_retum) how = RBTPANIC; 
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13470 } 

13471 

13472 if (how = RBT PANIC) { 

13473 /* ¡Un pánico! */ 

13474 printf("Hit ESC to reboot, F-keys for debug dumps\n"); 

13475 

13476 (void) scan_keyboard(); /* acusar rec. de entradas viejas */ 

13477 quiet = scan_keyboard()j/* valor latente (0 en PC, últ. cód. en AT)*/ 

13478 for (;;) { 

13479 milli_delay(100); /* pausa de 1 decisegundo */ 

13480 code = scan_keyboard(); 

13481 if (code != quiet) { 

13482 /* Se oprimió una tecla. */ 

13483 if (code = ESC_SCAN) break; /* rearrancar si ESC */ 

13484 (void) func_key(code); /* procesar tecla fimGo */ 

13485 quiet = scan_keyboard(); 

13486 } 

13487 } 

13488 how = RBTREBOOT; 

13489 } 

13490 

13491 if (how = RBT REBOOT) printf("Rebooting\n") j 

13492 

13493 if (mon retum && how 1 = RBT RESET) { 

13494 /* Reinicilizar controladores de ints. a valores de BIOS. */ 

13495 intr_init(0); 

13496 out_byte(INT_CTLMASK, 0); 

13497 out_byte (INT2CTLMASK, 0); 

13498 

13499 /* Regresar al monitor de arranque. */ 

13500 if (how = RBT HALT) { 

13501 reboot_code = vir2phys(""); 

13502 } else 

13503 if (how = RBT REBOOT) { 

13504 reboot_code = vir2phys("delaYjboot"); 

13505 } 

13506 levelO(monitor); 

13507 } 

13508 

13509 /* Detener prueba de memoria de BIOS. */ 

13510 phys copy(vir2phys(&magic), (phys bytes) MEMCHECKADR, 

13511 -(phys_bytes) sizeof(magic)); 

13512 

13513 if (protected mode) { 

13514 /* Usar el controlador en hardware del teclado AT para restablecer 

13515 * el procesador. La línea A20 se mantiene habilitada por si este código 

13516 * se ejecuta desde memoria extendida y porque algunas máquinas 

13517 * parecen subir la A20 falsa en vez de bajar la justo después del 

13518 * restablecimiento, dando pie a una trampa de cód. de operación 

13519 * ilegal. Este error es más problemático si está en uso la A20 falsa, 

13520 * como sucedería si se usara el reset de teclado para modo real. 

13521 */ 

13522 kb_wait(); 

13523 out_byte (KB COMMAND, 

13524 KB PULSE OUTPUT I (OxOF & -(KB GATE A20 I KB RESET))); 

13525 milli_delay(10); 

13526 

13527 /* Si el método amable falla, restablecer. En modo protegido esto implica 

13528 * un cese de funciones del procesador. 

13529 */ 
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13530 printf("Hard reset.. An"); 

13531 milli~delay(250); 

13532 } 

13533 /* En modo real, basta con saltar a la dirección de restablecimiento. */ 

13534 levelO(reset); 

13535 } 


src/kemel/console.c 


13600 /* Código y datos para el controlador de consola IBM. 

13601 * 

13602 * El controlador de video 6845 empleado por IBM PC comparte su memo de video 

13603 * con la CPU en algún lugar del banco OxBOOOO. Para el 6845 esta memoria 

13604 * consta de palabras de 16 bits. Cada una tiene un cód. de carácter en el byte bajo 

13605 * Y un byte de atributo en el alto. La CPU modifica directamente la memo de video 

13606 * p/exhibir caracteres, y fija dos registros del 6845 que espedí, el origen 

13607 * del video y la pos. del cursor. El origen es el lugar de la memo 

13608 * de video donde está el 1er. carácter (esquina supo izq.) Mover el origen 

13609 * es una forma rápida de desplazar la pantalla. Algunos adaptadores 

13610 * vinculan el final con el principio de la memo de video, y no hay límite 

13611 * para el mov. del origen. En otros a veces hay que mover la memo de video para 

13612 * restab. el origen. Todos los cálculos en memo de video usan direcciones 

13613 * de caro (palabra) por sencillez y suponen que no hay continuidad. Las funes. 

13614 * de apoyo traducen las direcciones de palabra a dirs. de byte y la tunco de 

13615 * despl. se preocupa por la continuidad. 

13616 */ 

13617 

13618 #include "kemel.h" 

13619 #include <termios.h> 

13620 #include <minix/callnr.h> 

13621 #include <minix/com.h> 

13622 #include "protect.h" 

13623 #include "tty.h" 

13624 #include "proc.h" 

13625 

13626 /* Definiciones empleadas por el controlador de la consola. */ 

13627 #define MONOBASE OxBOOOOL /* base de memoria de video mono */ 

13628 #define COLOR BASE 0xB8000L /* base de memoria de video de color */ 

13629 #define MONOS1ZE 0x1000 /* 4K memoria de video mono */ 

13630 #define COLOR S1ZE 0x4000 /* 16K memoria de video de color*/ 

13631 #define EGA_S1ZE 0x8000 /* EGA & VGA tienen al menos 32K */ 

13632 #define BLANKCOLOR 0x0700 /* determina color cursor en pant. vacía */ 

13633 #define SCROLL UP 0 /* desplazar ha9ia adelante */ 

13634 #define SCROLL DOWN 1 /* desplazar hacia atrás */ 

13635 #define BLANK-MEM ((ul6_t *) 0) /* dice a mem_vid_copy que borre pant. */ 

13636 #define CONS RAM WORDS 80 /* tamaño buffer de ram de video */ 

13637 #define MAX_ESC_PARMS 2 /*# de paráms. permito en seco escape */ 

13638 

13639 /* Constantes relacionadas con los chips controladores. */ 

13640 #define M_6845 0x3B4 /* puerto para 6845 mono */ 

13641 #define C_6845 0x3D4/* puerto para 6845 color */ 

13642 #defineEGA 0x3C4/* puerto para taq'eta EGA o VGA */ 

13643 #define INDEX 0 /* registro índice del 6845 */ 

13644 #defineDATA 1 /* registro de datos del 6845 */ 
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13645 

13646 
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13658 
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#defme VID_ORG 12 /* registro de origen del 6845 */ 

#defme CURSaR 14 /* registro de cursor del 6845 */ 


/* Alarma sonora. */ 

#defme BEEPFREQ 
#defme BTIME 


0x0533 /* valor p/temporiz.: frec. de bip */ 

3 /* long. del bip CTRL-G en tics */ 


/* definiciones empleadas en la administración de fuentes */ 

#define GA_SEQUENCER_INDEX0x3C4 
#define GASEQUENCERDATA 0x3C5 
#define GAGRAPHICSINDEX 0x3CE 
#define GA GRAPHICS DATA 0x3CF 
#define GA VIDEO ADDRES S OxAOOOOL 
#define GAFONTSIZE 8192 


/* Variables globales empleadas por el controlador de consola. */ 

PUBLIC unsigned vid seg; /* selector ram de video (OxBOOOO 

PUBLIC unsigned vid size; /* 0x2000 p/color o 0x0800 p/mono */ 

PUBLIC unsigned vid mask; /* OxlFFF p/color o 0x07FF p/mono */ 

PUBLIC unsigned blank color = BLANKCOLOR; /* cód. exhibo p/blanco */ 


/* Variables privadas empleadas por el controlador de consola. */ 

PRIVATE int vid_port; /* puerto E/S p/acceder a 6845 */ 

PRIVATE int wrap; /* ¿continuidad por hardware? */ 

PRIVATE int softscroll; /* 1 = despl. por sof., 0 = por hardware */ 
PRIVATE unsigned vid_base; /* base ram video (OxBOOO o 0xB800) */ 
PRIVATE int beeping; /* ¿altavoz hace bip? */ 

#define ser width80 /* núm. caracteres/línea */ 

#define scr=lines25 /* núm. líneas/pantalla */ 

#define scr_size (80*25) /* núm. caracteres/pantalla */ 


/* Datos por consola. * 
typedef struct consolé 
tty t *c tty; 
int-c column; 
int c=row; 
int c rwords; 
unsigned c_start; 
unsigned c_limit; 
gned c_org; 


unsigned 
unsigned c_attr; 
unsigned c_blank; 

char c-esc-intro; 
int *c-esc-parmp; 
int c_esc_parmv[MAX_ESC_PARMS]; 
ul6_t c_ramqueue[CONS_RAM_WORDS]; 
} console_t; 


/* struct TTY asociado */ 

/* núm. columna actual (0-origen) */ 

/* fila actual (0 arriba pantalla) */ 

/* núm WORDS (no bytes) en outqueue */ 
/* inicio de memo video esta consola */ 

/* límite de memo video esta consola */ 

/* lugar en RAM donde apunta base 6845 */ 
/* pos. actual de cursor en RAM video */ 

/* atributo de carácter */ 

/* atributo blanco */ 

/* 0=normal, 1=ESC, 2=ESC[ */ 

/* carácter distintivo sigue a ESC */ 

/* apunto a parám. de escape actual */ 

/* lista paráms. escape */ 
/* buffer p/RAM de video */ 


PRIVATE int nr_cons= 1; /* número real de consolas */ 
PRIVATE console_t cons_table[NR_CONS]; 

PRIVATE console_t *curcons; /* actualmente visible */ 

/* Color si se está usando controlador de color. */ 

#define color (vid_port = C_6845) 

/* Transformar colores ANSI a los atributos usados por la PC */ 

PRIVATE int ansi_colors[8] = {0, 4, 2, 6, 1, 5, 3, 7}; 




EL CÓDIGO FUENTE DE MINIX 


710 


Archivo: src/kemel/console.c 


13705 

13706 

13707 

13708 

13709 

13710 

13711 

13712 

13713 

13714 

13715 

13716 

13717 

13718 

13719 

13720 

13721 

13722 

13723 

13724 

13725 

13726 

13727 

13728 

13729 

13730 

13731 

13732 

13733 

13734 

13735 

13736 

13737 

13738 

13739 

13740 

13741 

13742 

13743 

13744 

13745 

13746 

13747 

13748 

13749 

13750 

13751 

13752 

13753 

13754 

13755 

13756 

13757 

13758 

13759 

13760 

13761 

13762 

13763 

13764 


/* Estructura empleada para administración de fuentes */ 
struct sequence { 

unsigned short índex; 
unsigned char port; 
unsigned char valué; 

}; 


FORWARD PROTOTYPE( void cons write, (struct tty *tp) 

FORWARD =PROTOTYPE( void cons=echo, (tty_t *tp, int c) 
FORWARD _PROTOTYPE( void out char, (console_t *cons, int c) 
FORWARD PROTOTYPE( void beep, (void) 

FORWARD -PROTOTYPE( void do escape, (consolé t *cons, int c) 
FORWARD -PROTOTYPE( void flush, (consolé t *cons) 

FORWARD =PROTOTYPE( void parseescape, (Console t *cons, int c) 
FORWARD PROTOTYPE( void scroll_screen, (consolé t *cons, int dir) 
FORWARD PROTOTYPE( void set 6845, (int reg, unsigned val) 
FORWARD =PROTOTYPE( void stop_beep, (void) 

FORWARD PROTOTYPE( void cons orgO, (void) 

FORWARD =PROTOTYPE( void ga_program, (struct sequence *seq) ); 


PRIVATE void cons write(tp) 

register struct tty *tp; /* dice cuál terminal debe usarse */ 

{ 

/* Copiar tantos datos como sea posible en cola de salida, e iniciar E/S. En 

* terminales con mapa en memoria, como la consola I8M, la E/S también se termina y 

* se actualizan las cuentas. Seguir repitiendo hasta terminar toda la E/S. 


register char *tbuf; 
char bUf[64]; 
phys_bytes user_phys; 
console_t *cons = tp->tty_priv; 

/* Verificar rápidamente que no haya nada que hacer, para que ésta pueda invocarse 

* a menudo sin pruebas no modulares en otros puntos. 

if ((count = tp->tty_outleft) ==011 tp->ttY_inhibited) retum; 

/* Copiar bytes de usuario en buf[] para un direccionamiento decente. Iterar las 

* copias, ya que el buffer de usuario podría ser mucho mayor que buf[ ]. 

do { 

if (count > sizeOf(buf)) count = SizeOf(buf); 

user_phys = proc_vir2Phys(proc_addr(tp->tty_outproc), tp->tty_out_vir); 
phys_copy(user_phys, vir2phys(buf) , (phys_bytes) count); 
tbuf = buf; 

/* Actualizar estructura de datos de terminal. */ 
tp->tty_out_vir += count; 
tp->tty_outcum += count; 
tp->tty_outleft -= countj 

/* Enviar cada byte de la copia a la pantalla. Evitar invocar out_char() 

* para los caracteres "fáciles"; colocarlos en el buffer 

* directamente. 


); 

); 

); 

); 

); 

); 

); 

); 

); 

); 

); 


=*/ 
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*/ 

do { 

if ((unsigned) *tbuf <',11 cons->c_esc_state > 0 
| | cons->c_column >= scr_width 
| | cons->c_rwords >= bUflen(cons->c_ramqueue» 

{ 

out_char(cons, *tbuf++); 

} else { 

cons->c_ramqueue[cons->c_rwords++j = 

cons->c_attr I (*tbuf++ & BYTE); 

cons->c_column++; 

} 

} while (—count != 0); 

} while ((count = tp->tty_outleft) 1= 0 && Itp->ttY_inhibited); 

fluSh(cons); /* transferir todo lo del buffer a la pantalla */ 


/* Re-sponder al escritor si terminaron todas las salidas. */ 
if (tp->tty_outleñ == 0) { 

tty_reply(tp->tty_outrepcOde, tp->tty_outcaller, tp->tty_outproc, 

tp->tty_outcum); 


} 


tp->tty_outcum = 0; 


13791 /*=================================================== == =* 

13792 * cons_echo * 

13793 *============================= == ================ == =============*/ 

13794 PRIVATE void cons_eCho(tp, c) 

13795 register tty_t *tp; /* apuntador a struct tty */ 

13796 inte; /* caro del que se hará eco */ 

13797 { 

13798 /* Hacer eco de entradas del teclado (imprimir y vaciar). */ 

13799 console_t *cons = tp->tty_priv; 

13800 

13801 out_char(cons, c); 

13802 fluSh(cons); 

13803 } 


13806 /*========================================= === ==============* 

13807 * out_char * 

13808 * = == -^^.. -.:====================== == ================ == =============*/ 

13809 PRIVATE void out_char(cons, c) 

13810 register console_t *cons; /* apuntador a struct de consola */ 

13811 inte; /* carácter por exhibir */ 

13812 { 

13813 /* Exhibir carácter en consola. Verifo primero secuencias de escape. */ 

13814 if (cons->c_esc_state > 0) { 

13815 parse_escape(cons, c); 

13816 retum; 

13817 } 

13818 

13819 switch(c) { 

13820 case 000: /* nuil suele usarse como relleno */ 

13821 retum; /* mejor no hacer nada */ 

13822 

13823 case 007: /* sonar la campana */ 

13824 fluSh(cons); /* exhibo caracteres en cola p/salida */ 
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beep(); 


case ' \ b /* retroceso */ 

if (—cons->c_column < 0) { 

if (—cons->c_row >= 0) cons->c_column += scr_width; 

} 

flush(cons); 


case' \ n /* salto de línea */ 

if ((cons->c_tty->tty_termios.c_oflag & (OPOSTIONLCR)) 

= (OPOSTIONLCR)) { 

cons->c_column = 0; 

} 

/*CONTINUAR CON RUTINA SIGUIENTE*/ 
case 013: /* CTRL-K */ 

case 014: /* CTRL-L */ 


if(cons->c_row==scr_lines-l) { 

scroll_screen(cons, SCROLLUP); 

} else { 

cons->c_row++; 

} 

flush(cons); 


/* retomo de < 
cons->c_column = 0; 
flush(cons); 


case ’ \ t ’: /* tab */ 

cons->c_column = (cons->c_column + TAB SIZE) & -TABMASK; 
if (cons->c_column > scr_width) { 

cons->c_column -= scr_width; 
if(cons->c_row==scr_lines-l) { 

scroll_screen(cons, SCROLL_UP)j 

} else { 

cons->c_row++; 

} 

} 

flush(cons); 

case 033: /* ESC -inicia secuencia de escape */ 

flush(cons); /* exhibo cars. en cola p/salida */ 

cons->c_esc_state = 1; /* marcar ESC como visto */ 

default: /* cars. imprimibles se guardan en ramqueue */ 

if (cons->c_column >= scr_width) { 
if (ILINEWRAP) retum; 
if(cons->c_row==scr_lines-l) { 

scroll_screen(cons, SCROLL UP); 

} else { 

cons->c_row++; 

} 

cons->c column = 0; 
flush(cons); 

} 
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13885 if (cons->c_rwords = bUflen(cons->c_ramqueue)) flush(cons); 

13886 cons->c_ramqueuelcons->c_rwords++] = cons->c_attr I (c & BYTE); 

13887 cons->c_column++; /* siguiente columna */ 

13888 retum; 

13889 } 

13890 } 

13893 /♦====== = = = ===== == =========== = = === === = = 

13894 * scroll_screen * 

13895 ♦ ==== ==== ====== ==== === == == === ====== = === 

13896 PRIVATE void scroll_screen(cons, dir) 

13897 register console_t *cons; /* apuntador a struct de consola */ 

13898 int dir; /* SCROLLUP o SCROLLDOWN */ 

13899 { 

13900 unsigned new_line, new_org, chars; 

13901 

13902 flush(cons); 

13903 chars = scr_size -scr_width; /* 1 pantalla menos 1 linea */ 

13904 

13905 /* Desplazar la pantalla es una lata por tantas taijetas de video incompatibles. 

13906 * Este controlador apoya despl. p/software (¿Hércules?), por hardware 

13907 * (tarjs. mono y CGA) y por hardware sin continuidad (EGA y VGA). 

13908 * En el tercer caso hay que asegurarse que se cumpla 

13909 * c_start <= c_org && c_org + scr_size <= cjimit 

13910 * porque EGA y VGA no continúan del fin al prinGo de la memo de video. 

13911 */ 

13912 if (dir = SCROLL UP) { 

13913 /* Despl. 1 línea arriba de 3 formas: soft, evitar cont., usar origen. */ 

13914 if (softscrOll) { 

13915 Vid_Vid_copy(cons->c_start + scr_width, cons->c_start, chars); 

13916 } else 

13917 if (!wrap && cons->c_org + scr_size + scr_width >= cons->c_limit) { 

13918 Vid_Vid_copy(cons->c_org + scr_width, cons->c_start, chars); 

13919 cons->c_org = cons->c_start; 

13920 } else { 

13921 cons->c_org = (cons->c_org + scr_width) & vid_mask; 

13922 } 

13923 new_line = (cons->c_org + chars) & vid_mask; 

13924 } else { 

13925 /* Despl. 1 línea abajo de 3 formas: soft, evitar cont., usar origen. */ 

13926 if (softscrOll) { 

13927 Vid_Vid_copy(cons->c_start, cons->c_start + scr_width, chars); 

13928 } else 

13929 if (!wrap && cons->c_org < cons->c_start + scr_width) { 

13930 new_org = cons->c_limit -scr_size; 

13931 Vid_Vid_copy(cons->c_org, new_org + scr_width, chars); 

13932 cons->c_org = new_org. 

13933 } else { 

13934 cons->c_org = (cons->c_org -scr_width) & vid_mask; 

13935 } 

13936 new_line = cons->c_org; 

13937 } 

13938 /* Poner en blanco la nueva línea arriba o abajo. */ 

13939 blank_color = cons->c_blank; 

13940 mem vid coPY(BLANK MEM, newjine, scr_width); 

13941 

13942 /* Establecer el nuevo origen de video. */ 

13943 if (cons = curcons) set_6845 (VID ORG, cons->c_org); 

13944 fluSh(cons); 
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13945 } 

139487*============================================================ 

13949 * flush * 

13950 *============================================================= 

13951 PRIVATE void flu’sh (cons) 

13952 register console_t *cons; 7 * apuntador a struct de consola *7 

13953 { 

13954 7 * Enviar caracteres en ’ramqueue' a memo de pantalla, verif. nueva 

13955 * pos. de cursar, calcular nueva pos. del cursar de hardware Y fijarla. 

13956 *7 

13957 unsigned cur; 

13958 tty_t *tp = cons->c_ttY; 

13959 

13960 7 * Transferir los caracteres de ’ramqueue' a la pantalla. *7 

13961 if (cons->c_rwords > 0) { 

13962 mem_vid_copy(cons->c_ramqueue, cons->c_cur, cons->c_rwords); 

13963 cons->c_rwords = 0; 

13964 

13965 7 * TTY gusta de conocer col. actual y si el eco se arruinó. *7 

13966 tp->tty_position = cons->c_column; 

13967 tp->tty_reprint = TRUE; 

13968 } 

13969 

13970 7 * Verificar Y actualizar la posición del cursar. *7 

13971 if (cons->c_column < 0) cons->c_column = 0; 

13972 if (cons->c_column > scr_width) cons->c_column = scr_width; 

13973 if (cons->c_row < 0) co~s->c_row = 0; 

13974 if (cons->c_row >= scr_lines) cons->c_row = scr_lines -1 ; 

13975 cur = cons->c_org + cons->c_row * scr_width + cons->c_column; 

13976 if (cur != cons->c_cur) { 

13977 if (cons == curcons) set_6845 (CURSOR, cur); 

13978 cons->c_cur = cur; 

13979 } 

13980 } 

139837*============================================================ 

13984 * parse_escape * 

13985 *============================================================= 

13986 PRIVATE void parse_escape(cons, c) 

13987 register console_t *cons; 7 * apuntador a struct de consola *7 

13988 char C; 7 * sigo carácter de secuencia escape *7 

13989 { 

13990 7 * Actualmente se reconocen las secuencias de escape ANSI siguientes: 

13991 * Si se omiten n y/o m, valen 1. Si se omite s, vale 0. 

13992 * ESC [nA sube n líneas 

13993 * ESC [nB baja n líneas 

13994 * ESC [nC se mueve n espacios a la derecha 

13995 * ESC [nO se mueve n espacios a la izquierda 

13996 * ESC [mjnH mueve el cursar a (m,n) 

13997 * ESC [sJ borra pantalla reí. al cursar (0 al fin, 1 del inicio, 2 todo) 

13998 * ESC [sK borra línea reí. al cursar (0 al fin, 1 del inicio, 2 todo) 

13999 * ESC [nL inserta n líneas en el cursar 

14000 * ESC [nM elimina n líneas en el cursar 

14001 * ESC [nP elimina n caracteres en el cursar 

14002 * ESC [n@ inserta n caracteres en el cursar 

14003 * ESC [nm habilita estilo n (0=normal, l=negra, 4=subray. 5=parpad, 

14004 * 7=inverso, 30. .37 color ler. plano, 40. .47 color 20. plano) 



’1 
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14005 

14006 

14007 

14008 

14009 

14010 

14011 

14012 

14013 

14014 

14015 

14016 

14017 

14018 

14019 

14020 

14021 

14022 

14023 

14024 

14025 

14026 

14027 

14028 

14029 

14030 

14031 

14032 

14033 

14034 

14035 

14036 

14037 

14038 

14039 


ESC M desplaza la pant. hacia atrás si el cursar está en la la. línea 


switch (cons->c_esc_state) { 
case 1: /* ESC visto*/ 

cons->c_esc_intro = ’\0'; 
cons >c_esc_parmp = cons ->c_esc_parmv; 
cons->c_esc_parmv[0] = cons->c_esc_parmv[l] = 0; 
switch (c) { 

case' [ /* Introductor de secuencia de control */ 

cons->c_esc_intro = c; 
cons->c_esc_state = 2; 
break; 

case ’M': /* Indice inverso */ 

do_escape(cons, c); 
break; 
default: 

} ™ S 

case 2: /* ESC [ visto */ 

if(c>='0'&&c<-9') { 

if (cons->c_esc_parmp < bufend(cons->c_esc_parmv)) 

*cons->c_esc_parmp = *cons->c_esc_parmp * 10 + (c- '0'); 

} else 

íf(c=’;'){ 

if (++cons->c_esc_parmp < bufend(cons->c_esc_parmv)) 
*cons->c_esc_parmp = 0; 

} el se { 

do_escape(cons, c); 


} 


14042 /♦==== ====== === ======= = ===== = = = ====== ♦ 

14043 * do_escape * 

14044 *===- ^ === ^--.. : = ==== ^ ======== == =============== === ==============*/ 

14045 PRIVATE void do_escape(cons, c) 

14046 register console_t *cons; /* apuntador a struct de consola */ 

14047 char c; /* sigo carácter de secuencia escape */ 

14048 { 

14049 int valué, n; 

14050 unsigned src, dst, count; 

14051 

14052 /* Algo de esto es hack de RAM de pantalla, más vale esté actualizado */ 

14053 flush(cons); 

14054 

14055 if (cons->c_esc_intro == '\0') { 

14056 /* Manejar una secuencia que comienza sólo con ESC */ 

14057 switch (c) { 

14058 case ’M': /* índice inverso */ 

14059 if (cons->c_row = 0 ) { 

14060 scroll_screen(cons, SCROLL DOWN); 

14061 } else { 

14062 cons->c_row—; 

14063 } 

14064 fluSh(cons); 
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14065 

break; 


14066 

14067 

default: break; 


14068 

} 


14069 

} else 


14070 

if (cons->c esc intro ='[') { 


14071 

/* Manejar secuencia que con 

lienza con ESC [ y parámetros */ 

14072 

valué = cons->c esc_parmv[0]; 

14073 

switch (c) { 


14074 

case 'A': 

/* ESC [nA sube n lineas */ 

14075 

n = (valué = 0 ? 1 : 

valué); 

14076 

cons->c row-=n; 


14077 

fluSh(cons); 


14078 

break; 


14079 

14080 

case ’B'- 

/* ESC [nB baja n lineas */ 

14081 

n = (valué = 0 ? 1 : 

valué); 

14082 

cons->c row+=n; 


14083 

flush(cons); 


14084 

break; 


14085 

14086 

case ’C: 

/* ESC [nC mueve n espacios a la derecha */ 

14087 


n = (valué = 0 ? 1 : valué); 

14088 


cons->c column += n; 

14089 

fluSh(cons); 


14090 

break; 


14091 

14092 

case ’D': /’ 

* ESC [nO mueve n espacios a la izq. */ 

14093 

n = (valué = 0 ? 1 

: valué); 

14094 

cons->c column -= 

= n; 

14095 

flush(cons); 


14096 

break; 


14097 

14098 

case ’H’: /= 

* ESC [mjnH" mueve cursar a (m,n) */ 

14099 

cons->c row = con 

ls->c esc_parmv[0] -1 ; 

14100 

cons->c column = 

cons->c esc_parmv[l] -1 ; 

14101 

flush(cons); 


14102 

break; 


14103 

14104 

case ’J’: / : 

* ESC [sJ despeja la pantalla */ 

14105 

switch (valué) { 


14106 

case 0: /’ 

* Borrar de cursar a fin pantalla */ 

14107 

count = ser 

size -(cons->c_cur -cons->c_org); 

14108 

dst = cons-> 

c cur; 

14109 

break; 


14110 

case 1: /■ 

* Borrar de princ. pantalla a cursar */ 

14111 

count = cons 

¡->c_cur -cons->c_org; 

14112 

dst = cons-> 

c_org; 

14113 

break; 


14114 

case 2: 

/* Borrar toda la pantalla */ 

14115 

count = ser 

size; 

14116 

dst = cons-> 

corg; 

14117 

break; 


14118 

default: /* 

No hacer nada */ 

14119 

count = 0; 


14120 

i 

c_org; 

14122 

1 

blank color = cons->c 

blank; 

14123 

mem vid copy (BLANK MEM , dst, count); 

14124 

break; 
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14125 

14126 

14127 

14128 

14129 

14130 

14131 

14132 

14133 

14134 

14135 

14136 

14137 

14138 

14139 

14140 

14141 

14142 

14143 

14144 

14145 

14146 

14147 

14148 

14149 

14150 

14151 

14152 

14153 

14154 

14155 

14156 

14157 

14158 

14159 

14160 

14161 

14162 

14163 

14164 

14165 

14166 

14167 

14168 

14169 

14170 

14171 

14172 

14173 

14174 

14175 

14176 

14177 

14178 

14179 

14180 

14181 

14182 

14183 

14184 


’K':/* ESC [sK borra línea desde el cursar */ 
switch (valué) { 

case 0: /* Borrar de cursar a fin de línea */ 

count = scr_width -cons->c_column; 
dst = cons->c_cur; 

case 1: /* Borrar de prinGo línea a cursar */ 

count = cons->c_column; 
dst = cons->c_cur -cons->c_column; 

case 2: /* Borrar toda la línea */ 

count = scr_width; 
dst = cons->c_cur -cons->c_column; 

default: /* No hacer nada */ 

count = 0; 


} 

blank_color = cons->c_blankj 
memvidcoPY(BLANKMEM, dst, count); 


if (n < 1) n = 1; 
if (n > (scr_lines 


/* ESC [nL inserta n líneas 


-cons->c_row)) 
r_lines -cons->c_row; 


. cursar */ 


src = cons->c_org + cons->c_row * scr_width; 

dst = src + n * scr_width; 

count = (scr_lines -cons->c_row -n) * scr_width; 

vid_vid_coPy(src, dst, count); 

blank_color = cons->c_blank; 

memvidcoPY (BLANKMEM, src, n * scrwidth); 


case ’M'; /* ESC [nM borra n líneas en el cursar */ 

if (n < 1) n = 1; 

if (n > (scr_lines -cons->c_row)) 

n = scr_lines -cons->c_row; 


dst = cons->c_org + cons->c_row * scr_width; 

src = dst + n * scr_width; 

count = (scr_lines -cons->c_row -n) * scr_width; 

vid_vid_copy(src, dst, count); 

blank_color = cons->c_blank; 

memvidcoPY (BLANKMEM, dst + count, n * scr_width); 


case /* ESC [n@ inserta n cars. en cursar */ 

n = valué; 
if (n< 1) n= 1; 

if (n > (scr_width -cons->c_column)) 

n = scr_width -cons->c_column; 
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14185 

14186 

14187 

14188 

14189 

14190 

14191 

14192 

14193 

14194 

14195 

14196 

14197 

14198 

14199 

14200 

14201 

14202 

14203 

14204 

14205 

14206 

14207 

14208 

14209 

14210 

14211 

14212 

14213 

14214 

14215 

14216 

14217 

14218 

14219 

14220 

14221 

14222 

14223 

14224 

14225 

14226 

14227 

14228 

14229 

14230 

14231 

14232 

14233 

14234 

14235 

14236 

14237 

14238 

14239 

14240 

14241 

14242 

14243 

14244 


vid_vid_copy(src, dst, count); 
blank_color = cons->c_blank; 
memvidcoPY(BLANKMEM, src, n); 


case ’P’: /* ESC [nP borra n cars. en cursar */ 

if(n< l)n= 1; 

if (n > (scr_width -cons->c_column)) 

n = scr_width -cons->c_column; 


dst = cons->c_cur; 
src = dst + n; 

count = scr_width -cons->c_column -n; 
vid_vid_copy(src, dst, count); 
blank_color = cons->c_blank; 
memvidcoPY (BLANKMEM, dst + count, n); 

e'm': /* ESC [nm habilita estilo n */ 

switch (valué) { 

case 1: /* NEGRITAS*/ 


b k 


/* No se puede, usar amarillo */ 

cons->c_attr = (cons->c_attr & OxfOff) I OxOEOO; 


/* Activar bit de intensidad */ 
cons->c_attr 1= 0x0800; 


/* SUBRAYAR */ 


/* Usar verde claro */ 
cons->c_attr = (cons->c_at 


-& OxfOff) IOxOAOO; 
- & 0x8900); 


/* PARPADEANTE *, 


/* Usar magenta */ 
cons->c_attr = (cons->c_at 


/* Activar bit de parpadeo */ 
cons->c_attr 1= 0x8000; 


• & OxfOff) 1 0x0500; 


case 7: /* INVERSO */ 

if (color) { 

/* Intercambiar colores ler/20 plano */ 

((cons->c_attr & OxfOOO)» 4) I 
((cons->c_attr & OxOfOO) « 4); 

} else 

if ((cons->c_attr & 0x7000) = 0) { 

cons->c_attr = (cons->c_attr & 0x8800) I 0x7000; 

} else { 
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14245 

14246 

14247 

14248 

14249 

14250 

14251 

14252 

14253 

14254 

14255 

14256 

14257 

14258 

14259 

14260 

14261 

14262 

14263 

14264 

14265 

14266 

14267 

14268 

14269 

14270 

14271 

14272 

14273 

14274 


cons->c_attr = (cons->c_attr & 0x8800) I 0x0700; 

} k 


default: /* COLOR */ 

if (30 <= valué && valué <= 37) { 
cons->c_attr = 

(cons->c_attr & OxfOff) | 
(ansi_colors[(value .30)]« 8); 

cons->c_blank = 

(cons->c_blank & OxfOff) | 
(ansi_colors[(value -30)]« 8); 

} else 

if (40 <= valué && valué <= 47) { 

(cons->c_attr & OxOfff) | 

(ansi_colors[(valué .40)] « 12); 

cons->c_blank = 

(cons->c_blank & OxOfff) | 

(ansi_colors {(valué-40)]« 12); 

} else { 

cons->c_attr = cons->c_blank; 






} 

} 


14277 /*================== == ======================= = ===== 

14278* set_6845 

14279 *============================== = ===================== == 

14280 PRIVATE vaid set_6845(reg, val) 

14281 int reg; /* qué par de registros establecer */ 

14282 unsigned val; /* valor de 16 bit para establecer */ 

14283 { 

14284 /* Establecer par de registros dentro de 6845. 

14285* Los regs. 12-13 dicen al 6845 dónde comenzar en ram de video 
14286* Los regs. 14-15 dicen al 6845 dónde poner el cursar 


14287 */ 

14288 lock(); /* intentar detener carga h/w valor intermedio */ 

14289 out_byte(vid_port + INDEX, reg); /* fijar registro índice */ 

14290 out_byte(vid_port + DATA, (val»8) & BYTE); /* byte alto a salida */ 

14291 out_byte(vid_port + INDEX, reg + 1); /* otra vez */ 

14292 out_byte(vid_port + DATA, val&BYTE); /* byte bajo a salida */ 

14293 unlock(); 

14294 } 


14297 /*==== == = = = == = = = == ==== = = = = == = = = ==== 

14298* beep 

14299 * = = = = = = = ===== = === = = = == = == = = = = === === = == = = 

14300 PRIVATE vaid beep() 

14301 { 

14302 /* Emitir alarma sonora por altavoz (salida de CTRL-G). 

14303* Esta rutina opera encendiendo los bits 0 Y 1 del puerto B del chip 8255 
14304* que controla el altavoz. 


*/ 


*/ 
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14305 */ 

14306 

14307 messagemess; 

14308 

14309 if (beeping) retum; 

14310 out_byte(TIMER_MODE, 0xB6); /* prep. temporiz. canal 2 (onda cuadr.) */ 

14311 out_byte(TIMER2, BEEPFREO & BYTE); /* cargar bits bajos de frec. */ 

14312 out_byte(TIMER2, (BEEP FREO» 8) & BYTE); /* ahora bits altos */ 

14313 lock(); /* proteger PORT_B del manej. int. teclado */ 

14314 out byte (PORTB, in byte (PORTB) I 3); /* activar bits de bip */ 

14315 unlock(); 

14316 beeping = TRUE; 

14317 

14318 mess.m_type = SET ALARM; 

14319 mess.CLOCK PROC NR = TTY; 

14320 mess.DELTA TICKS = B TIME; 

14321 mess.FUNC_TO_CALL = (sighandler_t) stop_beep; 

14322 sendrec(CLOCK, &mess); 

14323 } 

14326 /*======= = = = ======== = = = == = = = ======= = == = = ====== 

14327 * stopbeep * 

14328 * - - -- ===================== =,= ======== = ====== == ======= == 

14329 PRIVATE void stop_beep() 

14330 { 

14331 /* Apagar alarma sonora apagando bits 0 y 1 en PORT_B. */ 

14332 

14333 lock(); /* proteger PORT_B del manej. int. teclado */ 

14334 out byte (PORT B, in byte (PORT B) & -3); 

14335 beeping = FALSE; 

14336 unlock(); 

14337 } 

14340 /*============================================== = ======= == 

14341 * scr_init * 

14342 *============================= == =============== == ======= == 

14343 PUBLIC void scr_init(tp) 

14344 tty_t *tp; 

14345 { 

14346 /* Inicializar controlador en software de la pantalla. */ 

14347 console_t *cons; 

14348 phys_bytes vid_base; 

14349 ul6_t bios_crtbase; 

14350 intline; 

14351 unsigned page_size; 

14352 

14353 /* Asociar consola y TTY. */ 

14354 line = tp -&tty_table[0]; 

14355 if (line >= nr_cons) retum; 

14356 con s = &cons_table[line]; 

14357 cons->c_tty = tp; 

14358 tp->tty_priv = cons; 

14359 

14360 /* Inicializar controlador en software del teclado. */ 

14361 kb_init(tp); 

14362 

14363 /* Funciones de salida. */ 

14364 tp->tty_devwrite = cons_write; 
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14365 tp->tty_echo = cons_echo; 

14366 

14367 /* Obtener parámetros BIOS que dan a la VDU el registro base de E/S. */ 

14368 phys_copy(0x463L, vir2phys(&bios_crtbase), 2L); 

14369 

14370 vid_port = bioscrtbase; 

14371 

14372 if (color) { 

14373 vid_base = COLOR_BASE; 

14374 vid_size = COLOR_SIZE; 

14375 } else { 

14376 vid_base = MONOBASE; 

14377 vid_size = MONO_SIZE; 

14378 } 

14379 if (ega) vid_size = EGASIZE; /* tanto para EGA como VGA */ 

14380 wrap = lega; 

14381 

14382 vid_seg = protected_mode ? VIDEO_SELECTOR : physb_to_hclick(vid_base); 

14383 init_dataseg(&gdt[VIDEO_INDEX], vid_base, (phys_bytes) vid_size, 

14384 TASKPRIVILEGE); 

14385 vid_size »= 1; /* cuenta de palabras */ 

14386 vid_mask = vid_size-l; 

14387 

14388 /* Puede haber tantas consola s como la memoria de video permita. */ 

14389 nr_cons = vid_size / scr_size; 

14390 if (nr cons > NRCONS) nr cons = NR_CONS; 

14391 if (nr_cons > 1) wrap = 0; 

14392 page_size = vid_size / nr_cons; 

14393 cons->c_start = line * page_size; 

14394 cons->c_limit = cons->c_start + page_size; 

14395 cons->c_org = cons->c_start; 

14396 cons->c_attr = cons->c_blank = BLANKCOLOR; 

14397 

14398 /* Despejar la pantalla. */ 

14399 blank color = BLANK COLOR; 

14400 mem_vid_copy(BLANK_MEM, cons->c_start, scr size); 

14401 select_console(0); 

14402 } 

14405 /*======= = == = = = = = ====== = = = = == === = = == ==== = === = = == === = = ==== =====* 

14406 * putk * 

14407 * = = = = == === = = = === = = = = === = ======= = = = = = == = = = = = === == = = = = == = = = == */ 

14408 PUBLIC void putk(c) 

14409 int c; /* carácter por imprimir */ 

14410 { 

14411 /* La versión de printf() vinculada con el kemel mismo usa este procedimiento. 

14412 * El de la biblioteca envía un mensaje a FS, que no es lo que se necesita 

14413 * para imprimir dentro del kemel. Esta versión se limita a poner en cola el 

14414 * carácter e iniciar la salida. 

14415 */ 

14416 

14417 if (c != 0) { 

14418 if (c ==' \ n') putk(' \ r'); 

14419 out_char(&cons_table[0], (int) c); 

14420 } else { 

14421 flush(&cons_table[0]); 

14422 } 

14423 


} 
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toggle_scroll 


14428 * == == === === == == 

14429 PUBLIC void toggle_scroll() 

14430 { 

14431 /* Conmutar entre desplazamiento por hardware y por software. */ 

14432 

14433 cons_org0(); 

14434 soñscroll = ! softscroll; 

14435 printf("%sware scrolling enabledAn", soñscroll ? "80ft" : "Hard"); 

14436 } 


14439 /*===== 

14440 * 

14441 * = = === ==: 

14442 PUBLIC void C( 

14443 

14444 

14445 

14446 cons_org0(); 

14447 softscroll = 1; 

14448 select_conSole(0); 

14449 cons_,table[0] .c_attr = cons_table[0] ,c_blank = BLANK COLOR; 

14450 } 

14453 /*====== 

14454 * 

14455 *========== 

14456 PRIVATE void c< 

14457 { 

14458 /* Desplazar memoria de video hacia al 

14459 

14460 int consjine; 

14461 console_t * cons; 

14462 unsigned n; 

14463 

14464 for (cons_line = 0; ci 


/* Preparar paro o rearranque. */ 


is_org0 


s_org0() 


s para poner el origen en 0. */ 


14465 

14466 

14467 

14468 

14469 

14470 

14471 

14472 

14473 

14474 

14475 

14476 


is_line < nr_consj cons_line++) { 


is = &cons_table[cons_line]; 
while (cons->c_org > cons->c_start) { 

if (n > cons->c_org -cons->c_start) 

vid_vid_copy(cons->c_org, cons->c_org -n, 
cons->c_org -= n; 

} 

flush(cons); 

} 

select_conSole(current)j 


/* cantidad de memo no usada */ 


14479 /*== == ======= == === = 

14480 * 

14481 *======= == ===== = == 

14482 

select console(int con s line) 

14483 { 

14484 /* Asignar a la consola actual ni 


PUBLIC void 
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14485 

14486 if (cons_line <011 cons_line >= nr_cons) retum; 

14487 current = cons_line; 

14488 curcons = &cons_table[cons_line]; 

14489 set_6845(VID_ORG, curcons->c_org)j 

14490 set_6845(CURSOR, curcons->c_cur); 

14491 } 

14494 /♦================== == ======================= = ======== 

14495 * con_loadfont 

14496 *=========================== = = = =========================== 

14497PUBLIC int con_loadfont(user_phys) 

14498 phys_bytes user_phys; 

14499 { 

14500 /* Cargar una fuente en el adaptador EGA o VGA. */ 

14501 

14502 static struct sequence seql [7] = { 

14503 { GASEQUENCERINDEX, 0x00, 0x01 }, 

14504 { GA SEQUENCER INDEX, 0x02, 0x04 }, 

14505 { GA SEQUENCER INDEX, 0x04, 0x07 }, 

14506 { GA SEQUENCER INDEX, 0x00, 0x03 }, 

14507 { GAGRAPHICSINDEX, 0x04, 0x02 }, 

14508 { GA GRAPHICS INDEX, 0x05, 0x00 }, 

14509 { GA GRAPHICS INDEX, 0x06, 0x00 }, 

14510 }; 

14511 static struct sequence seq2[7] = { 

14512 { GA SEQUENCER INDEX, 0x00, 0x01 }, 

14513 { GA SEQUENCER INDEX, 0x02, 0x03 }, 

14514 { GA SEQUENCER INDEX, 0x04, 0x03 }, 

14515 { GA SEQUENCER INDEX, 0x00, 0x03 }, 

14516 { GA GRAPHICS INDEX, 0x04, 0x00 }, 

14517 { GA GRAPHICSJNDEX, 0x05, 0x10}, 

14518 {GA GRAPHICS INDEX, 0x06, 0}, 

14519 }; 

14520 

14521 seq2[6] ,value= color? OxOE : OxOA; 

14522 

14523 if (lega) retum(ENOTTY); 

14524 

14525 lockO; 

14526 ga_program(seql); /* traer a la vista la memoria de fuente */ 

14527 

14528 phys_copy(user_phys, (phys_bytes)GA VIDEO ADDRESS, (phys_bytes)GA_FONT_SIZE); 

14529 

14530 ga_program(seq2); /* restaurar */ 

14531 unlock(); 

14532 

14533 retum(OK); 

14534 } 


ga_program 


PRIVATE void ga_program(seq) 
truct sequence *seq; 

/* función de apoyo para con_loadfont */ 


14537 /’ 
14538* 

14539 * 

14540 

14541 

14542 

14543 

14544 
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14545 int len= 7; 

14546 do { 

14547 out_byte(seq->index, seq->port)j 

14548 out_byte(seq->index+l, seq->value); 

14549 seq++; 

14550 } while(-len>0); 

14551 } 


src/kemel/dmp.c 


14600 1 * Este archivo contiene rutinas de vaciado para depuración. *1 

14601 

14602#include "kemel.h" 

14603#include <minix/com.h> 

14604 #include "proc.h" 

14605 

14606 char *vargv; 

14607 

14608 FORWARO _PROTOTVPE(char *proc_name, (int proc_nr)); 

14609 

14610 1 *======================================= 


14611 * p_dmp * 

14612 *================================================================*7 


14613 PUBLIC voidp_dmp() 

14614 { 

14615 1 * Vaciado de tabla de procesos. *1 

14616 

14617 register struct proc *rp; 

14618 static struct proc *oldrp = BEG PROC ADDR; 

14619 int n = 0¡ 

14620 phys_clicks text, data, size; 

14621 intproc_nr; 

14622 

14623 printf("\n—pid —pe-sp- flag -user —sys— -text- -data- -size- -recv- command\n"); 

14624 

14625 for (rp = oldrp; rp < END PROC ADDRj rp++) { 

14626 proc_nr = proc_number(rp); 

14627 if (rp->p_flags & P SLOT FREE) continué; 

14628 if (++n > 20) break; 

14629 text = rp->p_map[T] ,mem_phys; 

14630 data = rp->p_map[D] .mem_phys; 

14631 size = rp->p_map[T] .memjen 

14632 + ((rp->p_map[S] .mem_phys + rp->p_map[S] .mem len) -data); 

14633 printf("%5d %51x %61x %2x %7U %7U %5uK %5uK %5uK ", 

14634 proe nr < 0 ? proe nr : rp->p_pid, 

14635 (unsigned long) rp->p_reg.pc, 

14636 (unsigned long) rp->p_reg.sp, 

14637 rp->p_flags, 

14638 rp->user_time, rp->sys_time, 

14639 click_to_round_k(text), click_to_round_k(data), 

14640 click_to_round_k(size)); 

14641 if (rp->p_flags & RECEIVING) { 

14642 printf("%-7.7s", proc_name(rp->p_getfrom)); 

14643 } else 

14644 if (rp->p_flags & SENDING) { 
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14645 printf("S:%-5.5S", proc_name(rp->p_sendto)); 

14646 } else 

14647 if (rp->p_flags = 0) { 

14648 printf(" "); 

14649 } 

14650 printf("%s\n", rp->p_name); 

14651 } 

14652 if (rp == END PRDC ADDR) rp = BEGPROCADDR; else printf("- 

14653 oldrp = rp; 

14654 } 




14657 /♦==== === ===== == ========= ===== = == = 

14658 * map_dmp * 

14659 ♦ ==== ==== ====== ==== ====== === ========== 

14660 PUBLIC void map_dmp() 

14661 { 

14662 register struct proc *rp; 

14663 static struct proc *oldrp = cproC_addr(HARDWARE); 

14664 int n = 0; 

14665 phys_clicks size; 

14666 

14667 printf("\nPROC ÑAME-TEXT-DATA-STACK-SI ZF -Vn"); 

14668 for (rp = oldrp; rp < END PROC ADDRj rp++) { 

14669 if (rp->p_flags & PSLOTFREE) continué; 

14670 if (++n > 20) break; 

14671 size = rp->p_map [T] .memlen 

14672 + ((rp->p_map[S] .mem_phys + rp->p_map[S] .mem_len) 

14673 -rp->p_map[D] ,mem_phys); 

14674 printf("%3d %-6.6s %4x %4x %4x %4x %4x %4x %4x %4x %4x %5uK\n" , 

14675 proc_number(rp), 

14676 rp->p_name, 

14677 rp->p_map[T].mem_vir, rp->p_map[T] .mem_phys , rp->p_map[T] .mem len, 

14678 rp->p_map[D].mem_vir, rp->p_map[D] ,mem_phys , rp->p_map[D] .mem len, 

14679 rp->p_map[S].mem_vir, rp->p_map[S] ,mem_phys, rp->p_map[S] .mem len, 

14680 click_to_round_k(size)); 

14681 } 

14682 if (rp = END PROC ADDR) rp = cproC addr(HARDWARE); else printf("-more-\r"); 

14683 oldrp = rp; 

14684 } 


14687 / H: ==================================== 

14688 * proc name 

14689 * - ■ -== = ======= == =========== - —= ===== 

14690 PRIVATE char *proc_name(proc_nr) 

14691 intproc_nr; 

14692 { 

14693 if(proc_nr = ANY) retum "ANY"; 

14694 retum proc_addr(proc_nr)->p_name; 

14695 } 
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src/kemel/sy stem. c 


14700/* Esta tarea maneja la interfaz entre el sist. arch. y el kemel y entre el 

14701 * adm. memo y el kemel. Los servicios de sistema se obtienen enviando un 

14702 * mensaje ~ sys_task() especificando qué se necesita. Para ayudar al MM y FS, 

14703 * hay una biblioteca con rutinas cuyos nombres tienen la forma sys_xxx, p.ej. 

14704 * sys_xit envía el mensaje SYS_XIT a sys_task. Los tipos de mensajes y sus 

14705 * parámetros son: 

14706 * 

14707 * SYS_FORK informa al kemel que un proceso bifurcó 

14708 * SYS NEWMAP permite a MM crear mapa de memoria de un proceso 

14709 * SYS=GETMAP permite a MM obtener mapa de memoria de un proceso 

14710 * SYS_EXEC fija contador de programa y apunto a pila después de EXEC 

14711 * SYS XIT informa al kemel que un proceso salió 

14712 * SYS-GETSP invocador desea leer el apunto a pila de algún proceso 

14713* SYS=TIMES invocador desea tiempos de contabil. de un proceso 

14714 * SYS A80RT MM o FS no puede continuar; abortar MINIX 

14715 * SYS=FRESH iniciar con nueva imagen de proceso durante EXEC (sólo 68000) 

14716 * SYS SENOSIG enviar una señal a un proceso (estilo POSIX) 

14717 * SYSSIGRETURN completar señalización estilo POSIX 

14718 * SYS KILL causar envío de señal vía MM 

14719 * SYS=ENOSIG acabar después de señal tipo SYSJCILL 

14720 * SYS_COPY solicitar copiado de un bloque de datos entre procesos 

14721 * SYS VCOPY solic. copiado de serie de bloques de datos entre procs 

14722 * SYS=GBOOT copia los parámetros de arranque a un proceso 

14723 * SYS MEM devuelve el siguiente trozo de memoria física libre 

14724 * SYS=UMAP calcula la dirección física de una dirección virtual dada 

14725 * SYS_TRACE solicita una operación de rastreo 

14726 * 

14727 * Tipos de mensajes y parámetros: 

14728 * 

14729* m type PROC1 PROC2 PIO MEM PTR 

14730 * 

14731 * 

14732 * 

14733 * 

14734 * 

14735 * 

14736* 

14737 * 

14738* 

14739 * 

14740 * 

14741 * 

14742 * 

14743 * 

14744 * 

14745 * 

14746 * 

14747 * 

14748 * 

14749 * 

14750* 

14751 

14752* m_type mi il ml_i2 ml_i3 ml_pl 

14753*-+-+-+-+- 

14754 * | SYS_VCOPY | p orig | p dest |tamvec |dirvc | 


SYSFORK 

| padre | hijo 

1 Pid 1 

SYS NEWMAP 

|# proc | 

| ap mapa 

SYSEXEC 

| # proc | rastro 

ja-pnvo | 

SYSXIT 

| padre | salió 

1 1 

SYSGETSP 

1 # proc || 

1 1 

| SYS TIMES 

|# proc | 

| ap buf | 

SYSABORT lili 

SYSFRESH 

| # proc |data_cl 

1 1 

SYSGBOOT 

|# proc | 

| | ap arr 

SYS GETMAP 

# proc | 

| ap mapa 
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14755 

14756 

14757 

14758 

14759 

14760 

14761 

14762 

14763 

14764 

14765 

14766 

14767 

14768 

14769 

14770 

14771 

14772 

14773 

14774 

14775 

14776 

14777 

14778 

14779 

14780 

14781 

14782 

14783 

14784 

14785 

14786 

14787 

14788 

14789 

14790 

14791 

14792 

14793 

14794 

14795 

14796 

14797 

14798 

14799 

14800 

14801 

14802 

14803 

14804 

14805 

14806 

14807 

14808 


1 

| SYS SENDSIG 

|# proc | 

1 1 

| smp 

1 

¡SYS SIGRETURN| # proc | 

1 1 

1 scp 

1 

| SYS ENDSIG 

|# proc | 


1 

1 

m_type 

m2_il 

m2_i2 

m2_ll m2_12 

| SYS TRACE 

| núm_proc 

| solic 

| direc | datos 

1 

m_type 

m6_il 

m6_i2 

m6_i3 m6_fl 


| SYS KILL 

| núm_proc 

| señal | 

1 1 


m_type m5_cl m5_il 

m5_ll m5_c2 

m5_i2 m5_12 m5 

¡_13 

| SYS_CDPY |seg org|proc org 

|vir org|seg dst |proc dst |vir dst | cta 

bytes I 

| SYS_UMAP| 

seg |núm_proc|dir vir | 

1 1 1 cta 

bytes 


* m_type ml_il ml_i2 ml_i3 

* |-+-+-+- 1 

*| SYS MEM | base mem |tammem| memtot| 


* Además del punto de entrada sys_task() principal, hay otros 5 puntos 

* de entrada secundarios: 

* cause_sig: tomar medidas para que ocurra una señal, tarde o temprano 

* inform: informar a MM de señales pendientes 

* numap: umap segmento D partiendo del # de proc en vez de apuntador 

* umap: calcular dirección física para una dirección virtual dada 

* alloc_segments: repartir segmentos para procesador 8088 o mayor 


#include "kemel.h" 

#include <signal.h> 
#include <unistd.h> 
#include <sys/sigcontext.h> 
#include <sys/ptrace.h> 
#include <minix/boot.h> 
#include <minix/callnr.h> 
#include <minix/com.h> 
#include "proc.h" 

#include "protect.h" 

/* Máscaras PSW. */ 


14809 #defme IFMASK 0x00000200 
14810#defíne IOPL MASK 0x003000 

14811 

14812 PRIVATE message m; 

14813 

14814 FORWARD _PROTOTYPE( int do_abort, (message *m_ptr) ); 
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14815 FORWARD _PROTOTYPE( int do_copy, (message *m_ptr) ); 

14816 FORWARD _PROTOTYPE( int do_exec, (message *m_ptr)); 

14817 FORWARD _PROTOTYPE( int do_fork, (message *m_ptr) ); 

14818 FORWARD _PROTOTYPE( int do_gboot, (message *m_ptr)); 

14819 FORWARD _PROTOTYPE( int do_getsp, (message *m_ptr)); 

14820 FORWARD _PROTOTYPE( int do_kill, (message *m_ptr)); 

14821 FORWARD _PRÜTOTYPE( int do_mem, (message *m_ptr)); 

14822 FORWARD _PROTOTYPE( int do_newmap, (message *m_ptr) ); 

14823 FORWARD _PROTOTYPE( int do_sendsig, (message *m_ptr)); 

14824 FORWARD _PROTOTYPE( int do_sigretum, (message *m_ptr)); 

14825 FORWARD _PROTOTYPE( int do_endsig, (message *m_ptr)); 

14826 FORWARD _PROTOTYPE( int do_times, (message *m_ptr)); 

14827 FORWARD _PROTOTYPE( int do_trace, (message *m_ptr)); 

14828 FORWARD _PROTOTYPE( int do_umap, (message *m_ptr)); 

14829 FORWARD _PROTOTYPE( int do_xit, (message *m_ptr)); 

14830 FORWARD _PROTOTYPE( int do_vcopy, (message *m_ptr)); 

14831 FORWARD _PROTOTYPE( int do getmap, (message *m_ptr)); 

14832 

14833 

14834 /*============================================= = ============== 

14835 * sys_task * 

14836 *== = === = ====== = = == = = ==== = ==== = = = == = === = == = ===== = === == = = ==== = === = = 

14837 PUBLIC void sys_task() 

14838 { 

14839 /* Pta. entrada principal de sys_task. Obt. mensaje y despachar según tipo. */ 

14840 

14841 register int r; 

14842 

14843 while (TRUE) { 

14844 receive(ANY, &m); 

14845 

14846 switch (m.m_type) { /* cuál llamada al sistema */ 

14847 case SYS_FORK: r = do_fork(&m); break; 

14848 case SYS_NEWMAP: r = do_newmap(&m); break; 

14849 case SYS_GETMAP: r = do_getmap(&m); break; 

14850 case SYS_EXEC: r = do_exec(&m); break; 

14851 case SYS XIT: r = do_xit(&m); break; 

14852 case SYS_GETSP: r = do_getsp(&m); break; 

14853 case SYS_TIMES: r = do_times(&m); break; 

14854 case SYS_ABORT: r = do_abort(&m); break; 

14855 case SYS_SENDSIG: r = do_sendsig(&m); break; 

14856 case SYS SIGRETURN: r= do_sigretum(&m); breakj 

14857 case SYS_KILL: r = do_kill(«fem); break; 

14858 case SYS_ENDSIG: r ~ do_endsig(&m); break; 

14859 case SYS_COPY: r = do_copy(&m); break; 

14860 case SYS_VCOPY: r = do_vcopy(&m); break; 

14861 case SYS_GBOOT: r = do_gboot(&m); break; 

14862 case SYS MEM: r = do_mem(&m)j break; 

14863 case SYSJJMAP: r = do_umap(&m); break; 

14864 case SYS_TRACE: r = do_trace(&m); break; 

14865 default: r = EBADFCN; 

14866 } 

14867 

14868 m.m_type = r; /* ’r' informa situación de llamada */ 

14869 send(m.m_source, &m); /* enviar respuesta al invocador */ 

14870 } 

14871 } 


14874, 
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14875 * do_fork 

14876 *====================== = ======= = ======= = ===== ==== = 

14877PRIVATE int do_fork(m_ptr) 

14878register message *m_ptrj /* apuntador a mensaje de solicitud */ 

14879 { 

14880/* Manejar sys_fork(). m_ptr->PROCl bifurcó. El hijo es m_ptr->PROC2. */ 

14881 

14882 reg_t old_ldt_sel; 

14883 register struct proc *rpc; 

14884 struct proc *rpp; 

14885 

14886 if(!isoksusem(m_ptr->PROCl) 11 !isoksusem(m_ptr->PROC2)) 

14887 retum(E_B ADPROC); 

14888 rpp = proc_addr(m_ptr->PROC 1); 

14889 rpc = proc_addr(m_ptr->PROC2); 

14890 

14891 /* Copiar struct 'proc' del padre al hijo. */ 

14892 old_ldt_sel = rpc->p_ldt_sel; /* evitar que copia destruya esto */ 

14893 

14894 *rpc = *rpp; /* copiar estructura 'proc' */ 

14895 

14896 rpc->p_ldt_sel = old_ldt_sel; 

14897 rpc->p_nr = m_ptr->PROC2; /* la copia destruyó esto */ 

14898 

14899 rpc->p_flags 1= NO_MAP; /* inhibir ejecución del proceso */ 

14900 

14901 rpc->p_flags &= -(PENDING 1 SIGPENDING 1 P_STOP); 

14902 

14903 /* Sólo 1 del grupo debe tener PENDING, hijo no hereda situac. rastreo*/ 

14904 sigemptyset(&rpc->p_pending); 

14905 rpc->p_pendcount = 0; 

14906 rpc->p_pid = m_ptr->PID; /* instalar pid del hijo */ 

14907 rpc->p_reg.retreg = 0; /* hijo ve pid = 0 p/saber que es hijo */ 

14908 

14909 rpc->user_time = 0; /* poner en 0 tiempos de contabil. */ 

14910 rpc->sys_time = 0; 

14911 rpc->child_utime = 0; 

14912 rpc->child_stime = 0; 

14913 

14914 retum(OK); 

14915 } 

14918 /*================== === ====================== ==== 

14919* do_newmap 

14920 * - ================ = ^ === - - - -== === ====== == ===== ======== === 

14921PRIVATE int do_newmap(m_ptr) 

14922 message *m_ptr;/* apunto a mensaje de solicitud */ 

14923 { 

14924 /* Manejar sys_newmap(). Traer mapa de memoria del MM. */ 

14925 

14926 register struct proc *rp; 

14927 phys_bytes src_phys; 

14928 int caller; /* espacio de quien tiene nvo. mapa (norm. MM) * 

14929 int k; /* proceso cuyo mapa debe cargarse */ 

14930 int oíd flags; /* valor de banderas antes de modificación */ 

14931 struct mem_map *map_ptr; /* dir. virtual de mapa dentro invocador (MM) */ 

14932 

14933 /* Extraer parámetros del mensaje y copiar nuevo mapa de memoria de MM. */ 

14934 caller = m_ptr->m_source; 
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14935 k = m_ptr->PROC 1; 

14936 map_ptr = (struct memmap *) m_ptr->MEM_PTR; 

14937 if (!isokprocn(k)) retum(EBADPROC); 

14938 rp = proc_addr(k); /* apunto a entrada de usuario que obt. nvo. mapa */ 

14939 

14940 /* Copiar el mapa de MM. */ 

14941 src_phys = umap'(proc_addr(caller), D, (vir_bytes) map_ptr, Sizeof(rp->p_map)); 

14942 if (src_phys = 0) panic("bad cali to sys_newmap", NO_NUM); 

14943 phys_copy(src_phys, vir2phys(rp->p_map), (phys_bytes) Sizeof(rp->p_map)); 

14944 

14945 alloc_segments(rp); 

14946 old_flags = rp->p_flags; /* guardar valor previo de banderas */ 

14947 rp->p_flags &= -NO_MAP; 

14948 if (old_flags != 0 && rp->p_flags = 0) lock_ready(rp); 

14949 

14950 retum(OK); 

14951 } 

14954 /♦==== ======== = ======= = === == = = == 

14955 * do_getmap 

14956 *== === ===== = = = = = === = == == = == == = = = = == == = = == = 

14957 PRIVATE int do_getmap(m_ptr) 

14958 message *m_ptr; /* apuntador a mensaje solicitud */ 

14959 { 

14960 /* Manejar sys_getmap(). Informar mapa de memoria a MM. */ 

14961 

14962 register struct proc *rp; 

14963 phys_bytes dst_phys; 

14964 int caller; /* dónde guardar el mapa */ 

14965 int k; /* proceso cuyo mapa se carga */ 

14966 struct mem_map *map_ptr; /* dir. virtual de mapa dentro invocador (MM) */ 

14967 

14968 /* Extraer parámetros del mensaje y copiar nuevo mapa de memoria en MM. */ 

14969 caller = m_ptr->m_source; 

14970 k = m_ptr->PROCl ; 

14971 map_ptr = (struct mem map *) m_ptr->MEM_PTR; 

14972 

14973 if (!isokproCn(k)) 

14974 panic("do_getmap got bad proc: ", m_ptr->PROCl); 

14975 

14976 rp = proc_addr(k); /* apunto a entrada del mapa */ 

14977 

14978 /* Copiar el mapa en MM. */ 

14979 dst_phys = umap(proc_addr(caller), D, (vir_bytes) map_ptr, SizeOf(rp->p_map)); 

14980 if (dst_phys = 0) panic("bad cali to sys_getmap", NO_NUM); 

14981 phys_copy(vir2phys(rp->p_map), dst_phys, sizeOf(rp->p_map)); 

14982 

14983 retum(OK); 

14984 } 

14987 /♦==== ========= = ======= = === = = = == 

14988 * doexec 

14989 ♦============ = = = ===== = ==== == = == == = = = == ==== = == = 

14990 PRIVATE int do_exec(m_ptr) 

14991 register message *m_ptr; /* apuntador a mensaj~ solicitud */ 

14992 { 

14993 /* Manejar sys_exec(). Un proceso hizo EXEC con éxito. Parcharlo. */ 

14994 




*/ 














731 


EL CÓDIGO FUENTE DE MINIX Archivo: src/kemel/system.c 

14995 register struct proc *rp; 

14996 reg_t sp; /* nuevo apuntador a pila */ 

14997 phys_bytes phys_name; 

14998 char *np; 

14999 #defíne NLEN (sizeof(rp->p_name) -1) 

15000 

15001 if (!isoksusem(m_ptr->PROC 1)) retum EBADPROC; 

15002 /* Campo PROC2 sirve como bandera p/indicar que el proc. es rastreado. */ 

15003 if (m_ptr->PROC2) cause_sig(m_ptr->PROCl, SIGTRAP); 

15004 sp = (reg_t) m_ptr->STACK_PTR; 

15005 rp = proc_addr(m_ptr->PROCl); 

15006 rp->p_reg.sp = sp; /* fijar apuntador a pila */ 

15007 rp->p_reg.pc = (reg_t) m_ptr->IP_PTR; /* fijar contador programa */ 

15008 rp->p_alarm = 0; /* restab. temporiz. alarma */ 

15009 rp->p_flags &= -RECEIVING; /* MM no contesta a llamada EXEC */ 

15010 if (rp->p_flags == 0) lock_ready(rp); 

15011 

15012 /* Guardar nombre de comando p/depuración, salida ps(l), etc. */ 

15013 phys_name = numap(m_ptr->m_source, (vir_bytes) m_ptr->NAME_PTR, 

15014 (vir_bytes) NLEN); 

15015 if (phys name != 0) { 

15016 phys_copy(phys_name, vir2phys(rp->p_name), (phys_bytes) NLEN); 

15017 for (np = rp->p_name; (*np & BYTE) >= ''; np++) {} 

15018 *np = 0; 

15019 } 

15020 retum(OK); 

15021 } 

15024 /♦================= = ================= = ======= = ======= 

15025 * do_xit 

15026 ♦== === ===== = = = ==^==== = == = = = ==== = == = = === = == 

15027 PRIVATE int do_xit(m_ptr) 

15028message *m_ptr; /* apunto a mensaje solicitud */ 

15029 { 

15030 /* Manejar sys_xit(). Un proceso salió. */ 

15031 

15032 register struct proc *rp, *rc; 

15033 struct proc *np, *xp; 

15034 int parent; /* núm. del padre del proc. que sale */ 

15035 int proc_nr; /* núm. del proceso que sale */ 

15036 phys_clicks base, size; 

15037 

15038 parent = m_ptr->PROCl; /* núm. ranura de proc. padre */ 

15039 proc_nr = m_ptr->PROC2; /* núm. ranura de proc. que sale */ 

15040 if (!isoksusem(parent) 11 !isOksusem(proc_nr)) retum(E_BAD_PROC); 

15041 rp = proc_addr(parent); 

15042 re = proc_addr(proc_nr); 

15043 lock(); 

15044 rp->child_utime += rc->user_time + rc->child_utime; /* tiempos acum. hijo */ 

15045 rp->child_9time += rc->sys_time + rc->child_stime; 

15046 unlockO; 

15047 rc->p_alarm = 0; /* apagar temporizador de alarma */ 

15048 if (rc->p_flags = 0) lock_unready(rc); 

15049 

15050 strcpy(rc->p_name, "<noname>"); /* el proc. ya no tiene nombre */ 

15051 

15052 /* Si el proceso terminado está formado en cola 

15053 * tratando de enviar un mensaje (o sea, una señal mató al proceso, 

15054 * él no hizo EXIT), deberá quitarse de las colas de mensaje. 




15055 

15056 

15057 

15058 

15059 

15060 

15061 

15062 

15063 

15064 

15065 

15066 

15067 

15068 

15069 

15070 

15071 

15072 

15073 

15074 

15075 

15076 

15077 

15078 

15079 

15080 

15081 

15082 

15083 

15086 

15087 

15088 

15089 

15090 

15091 

15092 

15093 

15094 

15095 

15096 

15097 

15098 

15099 

15100 
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if (rc->p_flags & SENDING) { 

\* Revisar todas ranuras de proc pjver si el proc que sale está ahi. *\ 
for (rp = BEGPROCADDR; rp < ENDPROCADDR; rp++) { 
if (rp->p_callerq = NIL PROC) continué; 
if (rp->p_callerq = re) { 

/* El proc que sale está a la cabeza de esta cola. */ 
rp->p_callerq = rc->p_sendlink; 
break; 

} else { 

\* Ver si el proc que sale está en medio de cola. *\ 
np = rp->p_callerq; 

while ( ( xp = np->p_sendlink) 1= NIL_PROC) 
if ( X P == re) { 

np->p_sendlink = xp->p_sendlink; 
break; 

} else { 


if (rc->p_flags & PENDING) -si g p rocs; 
sigemptyset(&rc->p_pending); 
rc->p_pendcount = 0; 
rc->p_flags = PSLOTFREE; 
retum(OK); 


{ 


PRIVATE int do_getsp(m_ptr) 

register message *m_ptr; /* apunto a mensaje solicitud */ 
/* Manejar sys_getsp(). MM quiere conocer el apuntador a la pila (sp). */ 


register struct proc *rp; 

if (! isoksusem(m_ptr->PROC 1)) retum(E_B ADPROC); 

rp = proc_addr(m_ptr->PROC 1); 

m_ptr->STACK_PTR = (char *) rp->p_reg.sp; /* devolver sp aquí (tipo mal) */ 

retum(OK); 


15103 /♦=== ==== == === == ====== = === = === == == 

15104 * do_times * 

15105 ♦== = == = ========= = == = = = ===== = = == == = = = == = == === = == = 

15106 PRIVATE int do_times (m_ptr) 

15107 register message *m_ptr; /* apunto a mensaje solicitud */ 

15108 { 

15109 /* Manejar sys_times(). Recuperar información de contabilidad. */ 

15110 

15111 register struct proc *rp; 

15112 

15113 if (lisoksusem(m_ptr->PROC 1)) retum 

15114 rp = proc_addr(m_ptr->PROCl); 


EBADPROC; 
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15115 

15116 /* Insertar tiempos req. por llamada al sist. TIMES en el mensaje. */ 

15117 loCk(); /* detener contadores de tiempo volátiles en rp *1 

15118 m_ptr->USER_TIME = rp->user_time; 

15119 m_ptr->S YSTEMTIME = rp->sys_time; 

15120 unloCk(); 

15121 m_ptr->CHILD_UTIME = rp->child_utime. 

15122 m_ptr->CHILD_STIME = rp->child_stime; 

15123 m_ptr->BOOT_TICKS = get_uptime(); 

15124 retum(OK); 

15125 } 

15128 1 *========================================================= 

15129 * doabort 

15130 * = = = = = = = === = = = = == = = = = = == === ====== = = = == = === = = = == = = = = = = = 

15131 PRIVATE int do_abort(m_ptr) 

15132 message *m_ptr; 1 * apunto a mensaje solicitud *1 

15133 { 

15134 1* Manejar sys_abort(). MINIX no puede continuar. Terminar operación. *1 

15135 char monitor_Code[64]; 

15136 phys_bytes src_phys; 

15137 

15138 if (m_ptr->ml_il == RBT MONITOR) { 

15139 1* Monitor debe ejecutar instrucciones especif. por usuario. *1 

15140 src_phys = numap(m_ptr->m_source, (vir_bytes) m_ptr->ml_pl, 

15141 (vir_bytes) sizeOf(monitor_Code)); 

15142 if (src_phys = 0) panic("bad monitor code from", m_Ptr->m_source); 

15143 phys_copy(Src_phys, vir2Phys(monitor_COde) 

15144 (phys_bytes) SizeOf(monitor_Code)); 

15145 reboot_code = vir2Phys(monitor_COde); 

15146 } 

15147 wreboot(m_Ptr->ml_il); 

15148 retum(OK); 1 * pro-forma (realmente EDISASTER) *1 

15149 } 

15154 1 *========================================================= 

15155 * do_sendsig 

15156 * = = = = = = = === = = = = == = = = === === = = ===== = = = == = == = = = == = = = = = = = 

15157 PRIVATE int do_sendsig(m_ptr) 

15158 message *m_ptr; 1 * apunto a mensaje solicitud */ 

15159 { 

15160 1* Manejar Sys_sendsig, señal estilo POSIX *1 

15161 

15162 struct sigmsg smsg; 

15163 register struct proc *rp; 

15164 phys_bytes src_phys, dst_phys; 

15165 struct sigcontext se, * sep; 

15166 struct sigframe fr, *frp; 

15167 

15168 if (lisokusem(m_ptr->PROCl» retum(E_BAD_PROC); 

15169 rp = proc_addr(m_Ptr->PROCl); 

15170 

15171 1* Traer estructura sigmsg a nuestro espacio de direcciones. *1 

15172 src_phys = umap(proc_addr(MM_PROC_NR), D, (vir bytes) m_ptr->SIG_CTXT_PTR, 

15173 (vir_bytes) sizeOf(struct sigmsg»; 

15174 


if (src_phys = 0) 
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15175 panic("do_sendsig can't signal: bad sigmsg address from MM", NO_NUM); 

15176 phys_copy(src_phys, vir2phys(&smsg), (phys_bytes) sizeof(struct sigmsg)); 

15177 

15178 /* Calcular valor de apunt a pila usuario donde se guardará sigcontext. */ 

15179 scp = (struct sigcontext *) smsg. sm_stkptr -1; 

15180 

15181 /* Cop.iar registros en estructura sigcontext. */ 

15182 memcpy(&sc.sc_regs, &rp->p_reg, sizeof(struct sigregs)); 

15183 

15184 /* Terminar la inicialización de signcontext. */ 

15185 sc.sc flags = SCSIGCONTEXT; 

15186 

15187 sc.sc_mask= smsg.smmask; 

15188 

15189 /* Copiar la estructura sigcontext en la pila del usuario. */ 

15190 dst_phys = umap(rp, D, (vir_bytes) scp, 

15191 (vir_bytes) sizeof(stmct sigcontext)); 

15192 if (dst_phys = 0) retum(EFAULT); 

15193 phys_copy(vir2phys(&sc), dst_phys, (phys_bytes) sizeof(struct sigcontext)); 

15194 

15195 /* Inicializar la estructura sigframe. */ 

15196 frp = (struct sigframe*) scp -1; 

15197 fr.sf_scpcopy = scp; 

15198 fr.sf_retadr2= (void (*) ()) rp->p_reg.pc; 

15199 fr.sf_fp = rp->p_reg.fp; 

15200 rp->p_reg.fp = (reg_t) &frp->sf_fp; 

15201 fr.sf_scp = scp; 

15202 fr.sfcode = 0; /* XXX -debe usarse p/tipo de excepción FP */ 

15203 fr.sf_signo = smsg.sm_signo; 

15204 fr.sf_retadr = (void (*)()) smsg.sm_sigretum; 

15205 

15206 /* Copiar la estructura sigframe en la pila del usuario. */ 

15207 dst_phys = umap(rp, D, (vir_bytes) frp, (vir_bytes) sizeof(stmct sigframe)); 

15208 if (dst_phys = 0) retum(EFAULT); 

15209 phys_copy(vir2phys(&fr), dst_phys, (phys_bytes) sizeof(stmct sigframe)); 

15210 

15211 /* Restablecer registros de usuario p/ejecutar el manejador de señales. */ 

15212 rp->p_reg.sp = (reg_t) frp; 

15213 rp->p_reg.pc = (reg_t) smsg.sm_sighandler; 

15214 

15215 retum(OK); 

15216 } 

15218 /♦==== == = = ===== == ==== == = ===== = == =♦ 

15219 * do_sigretum * 

15220 *== = - ^== ===============: =^.^ = ==================== == =============*/ 

15221 PRIVATE int do_sigretum(m_ptr) 

15222register message *m_ptr; 

15223 { 

15224/* Las señales estilo POSIX requieren sys_sigretum para ordenar las cosas antes 

15225 * de que el proceso señalizado pueda reanudar su ejecución 

15226 */ 

15227 

15228 struct sigcontext se; 

15229 register struct proc *rp; 

15230 phys_bytes src_phys; 

15231 

15232 if (!isokusem(m_ptr->PROCl)) retum(E_BAD_PROC); 

15233 rp = proc_addr(m_ptr->PROCl); 

15234 
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15235 /* Copiar la estructura sigcontext. */ 

15236 src_phys = umap(rp, D, (vir bytes) m_ptr->SIG_CTXT_PTR, 

15237 (vir_bytes) sizeof(struct sigcontext)); 

15238 if (src_phys = 0) retum(EFAULT); 

15239 phys_copy(src_phys, vir2phys(&sc), (phys_bytes) sizeof(struct sigcontext)); 

15240 

15241 /* Asegurarse de que no es s610 un jmp_buf. */ 

15242 if ((sc.sc_flags & SC_SIGCONTEXT) == 0) retum(EINVAL); 

15243 

15244 /* Arreglar s610 ciertos registros clave si el compilador no usa 

15245 * variables de registro dentro de las funciones que contienen setjmp. 

15246 */ 

15247 if (sc.sc_flags & SC_NOREGLOCALS) { 

15248 rp->p_reg.retreg = sc.sc_retreg; 

15249 rp->p_reg.fp = sc.scfp; 

15250 rp->p_reg.pc = sc.sc_pc; 

15251 rp->p_reg.sp = sc.sc_sp; 

15252 retum (OK); 

15253 } 

15254 sc.sc_psw = rp->p_reg.psw; 

15255 

15256 #if(CHIP== INTEL) 

15257 /* No asustar al kemel si el usuario dio selecto res malos. */ 

15258 sc.sc_cs = rp->p_reg.cs; 

15259 sc.sc_ds =rp->p_reg.ds; 

15260 sc.sc_es = rp->p_reg.es; 

15261 #if WORD SIZE = 4 

15262 sc.sc_fs = rp->p_reg.fs; 

15263 sc.sc_gs = rp->p_reg.gs; 

15264 #endif 

15265 #endif 

15266 

15267 /* Restaurar los registros. */ 

15268 memcpy(&rp->p_reg, (char *)&sc.sc_regs, sizeof(struct sigregs)); 

15269 

15270 retum(OK); 

15271 } 


15274* do_kill * 

15275 *============================== = ============================ 

15276 PRIVATE int do_kill(m_ptr) 

15277 register message *m_ptr; /* apunto a mensaje solicitud */ 

15278 { 

15279 /* Manejar sys_kill(). Causar envío de una señal a un proceso vía MM. 

15280 * Esto nada tiene que ver con la llamada al sistema kill (2), 

15281 * así es como el FS (y quizá otros servidores) obtienen acceso a cause_sig 

15282 * para enviar un mensaje KSIG a MM. 

15283 */ 

15284 

15285 if (!isokusem(m_ptr->PR)) retum(EBADPROC); 

15286 cause_sig(m_ptr->PR, m_ptr->SIGNUM); 

15287 return(OK)' 

15288 } 

15291 /*==== ========= = ======= = === = = = === = 

15292* do_endsig * 

15293 *== == ======== == == = ==== = = == ===== = = === === = = == == 

15294 PRIVATE int do_endsig(m_ptr) 
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15295 register message *m_ptr; /* apunto a mensaje solicitud */ 

15296 { 

15297 /* Asear después de señal tipo KSIG, causada por un mensaje SYS_KILL 

15298 * o una llamada a cause_sig por parte de una tarea 

15299 */ 

15300 

15301 register .struct proc *rp; 

15302 

15303 if (!isokusem(m_ptr->PROCl)) retum(E_BAD_PROC); 

15304 rp = proc_addr(m_ptr->PROCl); 

15305 

15306 /* MM ha concluido una KSIG */ 

15307 if (rp->p_pendcount != 0 && —rp->p_pendcount = 0 

15308 && (rp->p_flags &= -SIG_PENDING) = 0) 

15309 lock_ready(rp); 

15310 retum(OK); 

15311 } 

15313 /♦==== === ===== ======= = === = === = === 

15314 * do_copy * 

15315 ♦== == ======= = = = == == ==== === === = = = ===== == ===== = == === 

15316 PRIVATE int do_copy(m_ptr) 

15317 register message *m_ptr; /* apunto a mensaje solicitud */ 

15318 { 

15319 /* Manejar sys_copy(). Copiar datos para MM o FS. */ 

15320 

15321 int src_proc, dst_proc, src_space, dst_space; 

15322 vir_bytes src_vir, dst_vir; 

15323 phys_bytes src_phys, dst_phys, bytes; 

15324 

15325 /* Desmembrar el mensaje del comando. */ 

15326 src_proc = m_ptr->SRC_PROC_NR; 

15327 dst_proc = m_ptr->DST_PROC_NR; 

15328 src space = m_ptr->SRC_SPACE; 

15329 dst space = m_ptr->DST_SPACE; 

15330 src_vir = (vir bytes) m_ptr->SRC_BUFFER; 

15331 dst vir = (vir bytes) m_ptr->DST_BUFFER; 

15332 bytes = (phys_bytes) m_ptr->COPY_BYTES; 

15333 

15334 /* Calcular direcciones de origen y destino y hacer el copiado. */ 

15335 if(src_proc == ABS) 

15336 src_phys = (phys bytes) m_ptr->SRC_BUFFER; 

15337 else { 

15338 if (bytes != (vir_bytes) bytes) 

15339 /* Esto sucedería para segmentos de 64K y vir_bytes de 16 bits. 

15340 * Sucedería mucho con do_fork excepto que MM usa copias ABS 

15341 * para ese caso. 

15342 */ 

15343 panic("overflow in count in do_copy", NOJSTUM); 

15344 

15345 src_phys = umap(proc_addr(src_proc), src_space, src_vir, 

15346 (vir_b)hes) bytes); 

15347 } 

15348 

15349 if (dst_proc == ABS) 

15350 dst_phys = (phys bytes) m_ptr->DST_BUFFER; 

15351 else 

15352 dst_phys = umap(proc_addr(dst_proc), dst_space, dst_vir, 

15353 (vir_bytes) bjdes); 

15354 
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15355 if (src_phys = 011 dst_phys = 0) retum(EFAULT); 

15356 phys_copy(src_phys, dst_phys, bytes) j 

15357 retum(OK); 

15358 } 

15361 /*=== = = = = = === == = = = = = = = 

15362* dovcopy 

15363 * = ============= = == = ====== = ===.=== = = = === 

15364 PRIVATE int do vcopy(m ptr) 

15365 register message *m_ptr; /* apunto a mensaje solicitud */ 

15366 { 

15367 /* Manejar sys_vcopy(). Copiar múltiples bloques de memoria */ 

15368 

15369 int src_proc, dst_proc, vect_s, i; 

15370 vir_bytes src_vir, dst_vir, vect_addr; 

15371 phys_bytes src_phys, dst_phys, bytes; 

15372 cpvec t cpvec_table[CPVEC_NR]; 

15373 

15374 /* Desmembrar el mensaje del comando. */ 

15375 src_proc =m_ptr->ml_il; 

15376 dst_proc = m_ptr->ml_i2; 

15377 vect_s = m_ptr->m 1 _i3; 

15378 vect_addr = (vir_bytes)m_ptr->ml_pl; 

15379 

15380 if (vect s > CPVECNR) retum EDOM; 

15381 

15382 src_phys= numap (m_ptr->m_source, vect_addr, vect_s * sizeof(cpvec_t)); 

15383 if (!src_phys) retum EFAULT; 

15384 phys_copy(src_phys, vir2phys(cpvec_table), 

15385 (phys_bytes) (vect_s * sizeof(cpvec_t))); 

15386 

15387 for (i = 0; i < vect_s; i++) { 

15388 src_vir= cpvec_table[i] ,cpv_src; 

15389 dst_vir= cpvec_table[i] ,cpv_dst; 

15390 bytes= cpvec_table[i] .cpv size; 

15391 src_phys = numap(src_proc,src_vir, (vir_bytes)bytes); 

15392 dst_phys = numap(dst_proc,dst_vir, (vir_bytes)bytes); 

15393 if (src_phys = 011 dst_phys = 0) retum(EFAULT); 

15394 phys_copy(src_phys, dst_phys, bytes); 

15395 } 

15396 retum(OK); 

15397 } 

15400 /»== === = == == == = == = ==== = ==== = === 

15401* do_gboot * 

15402 * , , ====================== == ============================ 

15403 PUBLIC struct bparam s boot_parameters; 

15404 

15405 PRIVATE int do_gboot(m_ptr) 

15406 message *m_ptr; /* apunto a mensaje solicitud */ 

15407 { 

15408 /* Copiar paráms. de arranque. Normal, sólo se llama durante inic. de FS. */ 

15409 

15410 phys_bytes dst_phys; 

15411 

15412 dst_phys = umap(proc_addr(m_ptr->PROCl), D, (vir bytes) m_ptr->MEM_PTR, 

15413 (vir_bytes) sizeof(boot_parameters)); 

15414 if (dst_phys = 0) panic("bad cali to SYS_GBOOT", NO_NUM); 
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15415 phys_copy(vir2phys(&boot_parameters), dst_phys, 

15416 (phys_bytes) sizeof(boot_parameters)); 

15417 retum(OK); 

15418 } 

15421 /♦==== ======== = ==== == == = ===== = === = 

15422 * do mem * 

15423 *== == ==== == = = = == = = == == = == == = = ======= = == = 

15424 PRIVATE int do_mem(m_ptr) 

15425 register message *m_ptr; /* apunto a mensaje solicitud */ 

15426 { 

15427 /* Devolver base y tamaño del siguiente trozo de memoria. */ 

15428 

15429 struct memory *memp; 

15430 

15431 for (memp = mem; memp < &mem[NR_MEMS]; ++memp) { 

15432 m_ptr->ml_il = memp->base; 

15433 m_ptr->ml_i2 = memp->size; 

15434 m_ptr->ml_i3 = tot_mem_size; 

15435 memp->size = 0; 

15436 if (m_ptr->ml_i2 != 0) break; /* encontró un trozo */ 

15437 } 

15438 retum(OK); 

15439 } 


15442 /*==== = == = = = ====== = == == = 

15443 * do_umap 


15445 PRIVATE int do_umap(m_ptr) 

15446 register message *m_ptr; /* apunto a mensaje solicitud *1 

15447 { 

15448 1 * igual que umap(), para procesos sin kemel. *1 

15449 

15450 m_ptr->SRC_BUFFER = umap(proc_addr((int) m_ptr->SRC_PROC_NR), 

15451 (int) m_ptr->SRC_SPACE, 

15452 (vir bytes) m_ptr->SRC_BUFFER, 

15453 (vir bytes) m_ptr->COPY_BYTES); 

15454 retum(OK); 

15455 } 


15458 

15459 

15460 

15461 

15462 

15463 

15464 

15465 

15466 

15467 

15468 

15469 

15470 

15471 

15472 

15473 

15474 


do_trace 


#defme TR PROCNR 
#defme TR REQUEST 
#defme TR ADDR 
#defme TR DATA 
#defme TR VLSIZE 


(m_ptr->m2_il) 

(m_ptr->m2_i2) 

((vir_bytes) m_ptr->m2_l 1) 
(m_ptr->m2_12) 
((vir_bytes) sizeof(long)) 


PRIVATE int do_trace(m_ptr) 
register message *m_ptr; 

{ 

1 * Manejar los comandos de depuración apoyados por la llamada ptrace 

* Los comandos son: 

* T_STOP detener el proceso 

* T_OK habilitar rastreo por el padre de este proceso 

* T_GETINS devolver valor del espacio de instrucciones 
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15475 * T GETDATA devolver valor de espacio de datos 

15476 * T_GETUSER devolver valor de tabla de procesos de usuario 

15477 * T_SETINS fijar valor de espacio de instrucciones 

15478 * T_SETDATA fijar valor de espacio de datos 

15479 * T_SETUSER fijar valor en tabla de procesos de usuario 

15480 * T_RESUME reanudar ejecución 

15481 * T_EXlr salir 

15482 * T_STEP activar bit de rastreo 

15483 * 

15484 * El administrador de memoria maneja totalmente los comandos T_OK 

15485 * Y T_EXIT, todos los demás van aquí. 

15486 */ 

15487 

15488 register struct proc *rp; 

15489 phys_bytes src, dst; 

15490 intí; 

15491 

15492 rp = proc_addr(TR_PROCNR); 

15493 if (rp->p_flags & PSLOTFREE) retum(EIO); 

15494 switch (TR REQUEST) { 

15495 case T_STOP: /* detener proceso */ 

15496 if (rp->p_flags = 0) lock_unready(rp); 

15497 rp->p_flags 1= PSTOP; 

15498 rp->p_reg.psw &= -TRACEBIT; /* apagar bit de rastreo */ 

15499 retum(OK); 

15500 

15501 case T_GETINS: /* devolver valor de espacio de ins. */ 

15502 if (rp->p_map[T] .mem_len != 0) { 

15503 if ((src = umap(rp, T, TRADDR, TRVLSIZE)) == 0) retum(EIO); 

15504 phys_copy(src, vír2phys(&TR_DATA), (phys_bytes) sizeof(long)); 

15505 break; 

15506 } 

15507 /* Espacio texto es realmente espacio datos -continuar. */ 

15508 

15509 case T GETDATA: /* devolver valor de espacio de datos */ 

15510 if ((src = umap(rp, D, TR ADDR, TR VLSIZE)) = 0) retum(EIO); 

15511 phys_copy(src, vir2phys(&TR_DATA), (phys_bytes) sizeof(long)); 

15512 break; 

15513 

15514 case T_GETUSER: /* devolver valor de tabla de procs. */ 

15515 if ((TR ADDR & (sizeof(long) -1)) != 0 11 

15516 TR_ADDR> sizeof(stmct proc) -sizeof(long)) 

15517 retum(EIO); 

15518 TRDATA = *(long *) ((char *) rp + (int) TR ADDR); 

15519 break; 

15520 

15521 case T SETINS: /* fijar valor en espacio de instruc. */ 

15522 if (rp->p_map[T] .mem len != 0) { 

15523 if ((dst = umap(rp, T, TR ADDR, TR VLSIZE)) = 0) retum(EIO); 

15524 phys_copy(vir2phys(&TR_DATA), dst, (phys_bytes) sizeof(long)); 

15525 TRDATA = 0; 

15526 break; 

15527 } 

15528 /* Espacio texto es realmente espacio datos -continuar. */ 

15529 

15530 case T SETDATA: /* fijar valor en espacio de datos */ 

15531 if ((dst = umap(rp, D, TR ADDR, TR VLSIZE)) = 0) retum(EIO); 

15532 phys_copy(vir2phys(&TR_DATA), dst, (phys_bytes) sizeof(long)); 

15533 TRDATA = 0; 

15534 break; 
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15535 

15536 

caseT SETUSER: 

/* fijar valor en tabla de procs. */ 

15537 

if ((TR ADDR & (sizeof(reg_t) -1)) ! 

!=0 11 

15538 

TR_ADDR> sizeof(struct stackframe s) 

-sizeof(reg_t)) 

15539 

retum(EIO); 


15540 

i = (int) TR ADDR; 


15541 

#if (CHIP = INTEL) 


15542 

/* Alterar registros de segmentos podría causar 

una caída del kemel 

15543 

* cuando trate de cargarlos antes de reinicíar ui 

ti proceso, 

15544 

* así que no debe permitirse. 


15545 

*/ 


15546 

if (i = (int) &((struct proc *) 0)->p_reg.cs | | 


15547 

i == (int) &((struct proc *) 0)->p_reg.ds | 



15548 i == (int) &((struct proc *) 0)->p_reg.es 11 

15549 #if WORDSIZE = 4 

15550 i == (int) &((struct proc *) 0) ->p_reg.gs| | 

15551 i == (int) &((struct proc *) 0)->p_reg.fs 11 

15552 #endif 

15553 i == (int) &((struct proc *) 0) ->p_reg.ss) 

15554 retum(EIO); 

15555 #endif 

15556 if (i = (int) &((struct proc *) 0)->p_reg.psw) 

15557 /* sólo bits seleccionados son intercambiables */ 

15558 SETPSW(rp, TRDATA); 

15559 else 

15560 *(reg_t *) ((char *) &rp->p_reg + i) = (reg_t) TR DATA; 

15561 TRDATA = 0; 

15562 break; 

15563 

15564 case T RESUME: /* reanudar ejecución */ 

15565 rp->p_flags &= -P_STOP; 

15566 if (rp->p_flags = 0) lock_ready(rp); 

15567 TRDATA = 0; 

15568 break; 

15569 

15570 caseT_STEP: /* fijar bit de rastreo */ 

15571 rp->p_reg.psw 1= TRACEBIT; 

15572 rp->p_flags &= -P_STOP; 

15573 if (rp->p_flags = 0) lock_ready(rp); 

15574 TRDATA = 0; 

15575 break; 

15576 

15577 default: 

15578 retum(EIO); 

15579 } 

15580 retum(OK); 

15581 } 

15583 /♦====== == ======= ==== = = == ===== 

15584* cause_sig 

15585 * = = = = == ==== = = = = == = = = === ==== = = ===== = = = ===== = = = = = == = 

15586 PUBLIC void cause_sig(proc_nr, sig_nr) 

15587 intproc_nr; /* proceso por señalizar */ 

15588 int sig_nr; /* señal por enviar, 1 a _NSIG */ 

15589 { 

15590 /* Una tarea quiere enviar 1 señal a un proc. Ejemplos de tales tareas son: 

15591 * TTY quiere causar SIGINT al obtener un DEL 

15592 * CLOCK quiere causar SIGALRM cuando temporizador expira 

15593 * FS también usa esto p/enviar una señal, vía el mensaje SYS KILL. 

15594 * Las señales se manejan enviando un mensaje a MM. Las tareas no se atreven 
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15595 * a hacerlo directamente, por temor a lo que pasaría si MM estuviera 

15596 * ocupado, así que llaman cause_sig, que enciende bits en p_pending y 

15597 * luego ve con cuidado si MM está libre. Si así es, se le envía un mensaje. 

15598 * Si no, cuando queda libre se envía un mensaje. El proceso señalizado se 

15599 * bloquea si MM no ha visto o atendido todas las señales para él. Estas señales 

15600 * se cuentan en p_pendcount, y la bandera SIG_PENDING se mantiene no 0 mientras hay 

15601 * alguna.. No basta con preparar el proceso cuando se informa a MM, porque MM 

15602 * puede bloquearse esperando que FS haga un vaciado de núcleo. 

15603 */ 

15604 

15605 register struct proc *rp, *mmp; 

15606 

15607 rp = proc_addr(proc_nr); 

15608 if (sigismember(&rp->p_pending, sig_nr)) 

15609 retum; /* esta señal ya está pendiente */ 

15610 sigaddset(&rp->p_pending, sig_nr); 

15611 ++rp->p_pendcount; /* contar nueva señal pendiente */ 

15612 if (rp->p_flags & PENDING) 

15613 retum; /* otra señal ya pendiente */ 

15614 if (rp->p_flags == 0) lock_unready(rp); 

15615 rp->p_flags 1= PENDING 1 SIGPENDING; 

15616 ++sig_proCS; /* contar nuevo proceso pendiente */ 

15617 

15618 mmp = proc_addr(MM_PROC_NR); 

15619 if ( ((mmp->p_flags & RECEIVING) = 0) 11 mmp->p_getfrom != ANY) retum; 

15620 inform(); 

15621 } 

15624 /*======================================== === ============== 

15625 * inform * 

15626 * = = == = = === = = = == = = = = = = == === = = = = == = = = = = = == = = = = = = == = = = = == = === == 

15627 PUBLIC void inform() 

15628 { 

15629 /* Cuando el kernel detecta una señal (p.ej. DEL) o una tarea la genera (p.ej. 

15630 * la del reloj para SIGALRM), se invoca cause_sig() para activar un bit 

15631 * en el campo p_pending del proceso por señalizar. Luego se llama inform() 

15632 * para ver si MM está ocioso y se le puede informar. Siempre que MM se 

15633 * bloquea, se verifica si ’sig_procs' es dif. de 0; si así es, se invoca inform(). 

15634 */ 

15635 

15636 register struct proc *rp; 

15637 

15638 /* MM espera nuevas entradas. Encontrar un proc. con señales pendientes. */ 

15639 for (rp = BEG SERV ADDR; rp < END PROC ADDR; rp++) 

15640 if (rp->p_flags & PENDING) { 

15641 m.mtype = KSIG; 

15642 m.SIGPROC = proc_number(rp); 

15643 m.SIG_MAP = rp->p_pending; 

15644 sig_procs-; 

15645 if (lock_mini_send(proc_addr(HARDWARE), MM_PROC_NR, &m) != OK) 

15646 panic("can't inform MM", NO_NUM); 

15647 sigemptyset(&rp->p_pending); /* le toca a MM */ 

15648 rp->p_flags &= -PENDING;/* sigue inhibido por SIG PENDING */ 

15649 lock_pick_proc(); /* evitar retardo al planif. MM */ 

15650 retum; 

15651 } 

15652 } 
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15655 /*= 

15656 

15657 *= 

15658 

15659 

15660 

15661 

15662 

15663 

15664 

15665 

15666 

15667 

15668 

15669 

15670 

15671 

15672 

15673 

15674 

15675 

15676 

15677 

15678 

15679 

15680 

15681 

15682 

15683 

15684 

15685 

15686 

15687 

15688 

15689 

15690 

15691 




PUBLIC phys_bytes umap(rp, seg, vir_addr, bytes) 

register struct proc *rp; /* apunto a entrada del proc en tab proc */ 

int seg; /* segmento T, D o S */ 

vir_bytes vir_addr; /* dir. virtual en bytes dentro del segm */ 

vir_bytes bytes; /* núm. bytes por copiar */ 


/* Calcular dirección memoria física p/dirección virtual dada. */ 


vir_clicks ve; /* la dir. virtual está en clicks */ 

phys_bytes pa; /* variables intermedias como phys_bytes */ 

phys_bytes seg_base; 


/* Si 'seg' es D podría ser realmente S y viceversa. T si es T. 

* Si la dir. virtual cae en el espacio, causa un problema. En el 8088 quizá 

* es una referencia a pila legal, ya que el hardware no detecta "fallas de 

* pila". En los 8088, el espacio se llama S y se acepta, pero en otras máquinas 

* se llama D y se rechaza. 

* El Atari ST se comporta como el 8088. 

*/ 


if (bytes <= 0) retum( (phys_bytes) 0); 

ve = (vir_addr + bytes -1) »CLICK_SHIFT; /* últ. clic de datos */ 
if (seg !=T) 

seg = (ve < rp->p_map[D] .memvir + rp->p_map[D] .memlen ? D : S); 

if((vir_addr >> CLICK_SHIFT) >= rp->p_map[seg] .mem_vir+ rp->p_map[seg] .mem len) 
retum( (phys_bytes) 0). 

seg_base = (phys_bytes) rp->p_map[seg] ,mem_phys; 
segbase = segbase «CLICK SHIFTj /* origen de segmento en bytes */ 
pa = (phys_bytes) vir_addr; 
pa -= rp->p_map[seg] .mem vir « CLICK SHIFT; 
retum(seg_base + pa)j 


15694 /*================== == ============== = ======= 

15695 * numap 

15696 * ■ ■ ■ ■ ■ = ================= - — = === = ====== = ======= 

15697 PUBLIC phys_bytes numap(proc_nr, vir_addr, bytes) 

15698 int proc nr; /* núm. de proceso por mapear */ 

15699 vir_bytes vir_addr; /* dir. virtual en bytes dentro seg D */ 

15700 vir_bytes bytesj /* núm. bytes requeridos en segmento */ 

15701 { 

15702 /* Hacer umap() partiendo de un núm. de proceso en vez de un apuntador. 

15703 * Los controladores de dispositivos usan esta función, así que no necesitan 

15704 * saber de la tabla de procesos. Para ahorrar tiempo, no hay parámetro 'seg'. 

15705 * El segmento siempre es D. 

15706 */ 

15707 

15708 retum(umap(proc_addr(proc_nr), D, vir_addr, bytes)); 

15709 } 

15711 #if (CHIP == INTEL) 

15712 /♦=== ======= = = = ====== = === == 

15713 * alloc_segments 

15714 *== = ======== = ==== = = = ======= = ===== == == = = = = 


,*/ 


*/ 












EL CÓDIGO FUENTE DE MINIX 


Archivo: src/kemel/system.c 


743 


15715 PUBLIC void alloc_segments(rp) 

15716 register struct proc *rp; 

15717 { 

15718 /* Sólo do_newmap invoca ésta, pero es una función aparte 

15719 * porque muchas cosas dependen del hardware. 

15720 */ 

15721 

15722 phys_bytes code_bytes; 

15723 phys_bytes data_bytes; 

15724 int privilege; 

15725 

15726 if (protected_mOde) { 

15727 data_bytes = (phys_bytes) (rp->p_map[S] ,mem_vir + rp->p_map[SI.mem_len) 

15728 «CLICKSHIFT; 

15729 if (rp->p_map[T] .memjen = 0) 

15730 code_bytes = data_bytes; /* I&D común, mala protección */ 

15731 else 

15732 code bytes = (phys bytes) rp->p_map[T] .mem len « CLICK SHIFT; 

15733 privilege = istaskp(rp) ? TASK PRIVILEGE : USERPRIVILEGE; 

15734 init_codeseg(&rp->p_ldt[CS_LDT_INDEXI, 

15735 (phys bytes) rp->p_map[T] .mem_phys « CLICK SHIFT, 

15736 code_bytes, privilege); 

15737 init_dataseg(&rp->p_ldt[DS_LDT_INDEX], 

15738 (phys bytes) rp->p_map[D] ,mem_phys « CLICK SHIFT, 

15739 data_bytes, privilege); 

15740 rp->p_reg.cs = (CS_LDT_INDEX * DESC_SIZE) I TI I privilege; 

15741 #if WORD SIZE = 4 

15742 rp->p_reg.gs = 

15743 rp->p_reg.fs = 

15744 #endif 

15745 rp->p_reg.ss = 

15746 rp->p_reg.es = 

15747 rp->p_reg.ds = (DS_LDT_INDEX*DESC_SIZE) I TI I privilege; 

15748 } else { 

15749 rp->p_reg.cs = click_to_hcliCk(rp->p_map[T] ,mem_phys); 

15750 rp->p_reg.ss = 

15751 rp->p_reg.es = 

15752 rp->p_reg.ds = Click_to_hcliCk(rp->p_map[D] ,mem_phys); 

15753 } 

15754 } 

15755 #endif /* (CHIP = INTEL) */ 


src/mm/mm.h 


15800 /* La cabece,a maestra de MM. Incluye algunos otros archivos 

15801 * Y define las constantes principales. 

15802 */ 

15803 #define POSIX SOURCE 1 /* decir a cabeceras incluyan cosas POSIX */ 

15804 #define MINIX 1 /* decir a cabeceras incluyan cosas MINIX */ 

15805 #define =SYSTEM 1 /* decir a cabo que éste es el kemel */ 

15806 

15807 /* Éstas son tan básicas que todos los arch. *.c las incluyen automát. */ 

15808 #include <minix/config.h> /* DEBE ser primero */ 

15809 #include <ansi.h> /* DEBE ser segundo */ 
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15810 #include <sys/types.h> 

15811 #include <minix/const.h> 

15812 #include <minix/type.h> 

15813 

15814 #include <fcntl.h> 

15815 #include <unistd.h> 

15816 #include <min~x/syslib.h> 

15817 

15818 #include <limits.h> 

15819 #include <ermo.h> 

15820 

15821 #include "const.h" 

15822 #include "type.h" 

15823 #include "proto.h" 

15824 #include "glo.h" 


src/mm/const.h 


15900 /* Constantes empleadas por el administrador de memoria. */ 

15901 

15902 #defme NO_MEM ((phys_clicks) 0) /* devuelto por alloc_mem() si mem opera */ 

15903 

15904 #if (CHIP == INTEL && _WORD_SIZE == 2) 

15905 /* Estas definiciones se usan en size ok y no se necesitan para el 386. 

15906 * La granularidad del segmento de 386-es 1 para segmentos de menos de 1M y de 4096 

15907 * para segmentos mayores. 


15908 

15909 

15910 

15911 

15912 

15913 

15914 

15915 


#define PAGE SIZE 
#define MAXPAGES 


16 /* cuántos bytes en 1 pág. (s.b.HCLICK SIZE)*/ 

4096 /* cuántas págs. en el esp. de dir. virtual */ 


#define printf printk 


#define INIT_PID 1 /* núm. de id de proceso init */ 


src/mm/type.h 


16000 /* Si hubiera definiciones de tipos locales al administrador de memoria, 

16001 * estarían aquí. Sólo se incluye este archivo por simetría con el kemel 

16002 * Y FS, que sí tienen definiciones de tipos locales. 

16003 */ 

16004 
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16100 

/* Prototipos de funciones. */ 



16101 




16102 

struct mproc; /* 

necesita tipos afuera de lista de paráms. ..kub */ 


16103 

struct stat; 



16104 




16105 

/* alloc.c */ 



16106 

PROTOTYPEf phys clicks alloc mem, (phys cliCks cliCks) 

); 

16107 

PROTOTYPE( void free mem 

, (phys clicks base, phys clicks clicks) 

); 

16108 

PROTOTYPEf phys clicks nu 

x hole, (void) 

); 

16109 

PROTOTYPEf void mem init 

(phys cliCks *total, phys clicks *free) 

); 

16110 

PROTOTYPEf phys clicks mí 

m left, (void) 

); 

16111 

PROTOTYPEf int do brk3, (v 

oid) 

); 

16112 




16113 

/* break.c */ 



16114 

PROTOTYPEf int adjust, (struct mproc *rmp, 


16115 

vir 

clicks data clicks, vir bytes S p) 

); 

16116 

PROTOTYPEf int do brk, (vo 

id) 

); 

16117 

PROTOTYPEf int size ok. (int file tyne. vir clicks te. vir clicks de. 


16118 


vir clicks se, vir clicks dvi 

r, vir clicks s vir)); 

16119 




16120 

/* exec.c */ 



16121 

PROTOTYPEf int do exec, (v 

oid) 

); 

16122 

PROTOTYPEf struct mproc *fmd share, (struct mproc *mp ign, Ino t ino, 


16123 

Dev t dev, time t ctime) 

); 

16124 




16125 

/* forkexit.c */ 



16126 

PROTOTYPEf int do fork, (v 

lid) 

); 

16127 

PROTOTYPEf int do mm ex 

t, (void) 

); 

16128 

PROTOTYPEf int do waitpid, (void) 

); 

16129 

PROTOTYPEf void mm exit, 

(struct mproc *rmp, int exit status) 

); 

16130 




16131 

/* getset.c */ 



16132 

PROTOTYPEf int do getset, 

void) 

); 

16133 




16134 

/* main.c */ 



16135 

PROTOTYPEf void main, (ve 

id) 

); 

16136 




16137 

#if (MACHINE == MACINTOSH) 


16138 

PROTOTYPEf phys clicks st 

art click, (void) 

); 

16139 

#endif 



16140 




16141 

PROTOTYPEf void reply, fin 

proc nr, int result, int res2, char *respt»; 


16142 




16143 

/* putk.c */ 



16144 

PROTOTYPEf void putk, (int 

c) 

); 

16145 




16146 

/* signal.c */ 



16147 

PROTOTYPEf int do alarm. 

void) 

); 

16148 

PROTOTYPEf int do kill, (ve 

id) 

); 

16149 

PROTOTYPEf int do ksig, (v 

oid) 

); 

16150 

PROTOTYPEf int do_pause, 

void) 

); 

16151 

PROTOTYPEf int set alarm, 

(int proc nr, int sec) 

); 

16152 

PROTOTYPEf int check sis. (pid t proc id. int sisno) 

); 

16153 

PROTOTYPEf void sig proc. 

(struct mproc *rmp, int sig nr) 

); 

16154 

PROTOTYPEf int do sigaction, (void) 

); 
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16155 

16156 

16157 

16158 

16159 

16160 
16161 
16162 

16163 

16164 

16165 

16166 

16167 

16168 
16169 


_PROTOTYPE( int do_sigpending, (void) ); 
PROTOTYPE( int do sigprocmask, (void) ); 

_PROTOTYPE( int do-sigretum, (void) ); 
_PROTOTYPE( int do-sigsuspend, (void) ); 
_PROTOTYPE( int do=reboot, (void) ); 

/* trace.c */ 

PROTOTYPE( int do trace, (void) ); 

_PROTOTYPE( void stop_proc, (struct mproc *rmp, int sig_nr) ); 


/* utility.c */ 

PROTOTYPE( int allowed, (char *name_buf, struct stat *s_buf, int mask)); 

PROTOTYPE( int no sys, (void) ); 

_PROTOTYPE( void panic, (char *format, int num) ); 
_PROTOTYPE( void tell_fs, (int what, int pl, int p2, int p3) ); 


src/mm/glo.h 


16200 /* EXTERN debe ser extern excepto en table.c 

16201 #ifdef_TABLE 

16202 #undef EXTERN 

16203 #define EXTERN 

16204 #endif 

16205 

16206 /* Variables globales. */ 

16207 EXTERN struct mproc *mp; /* apunto a ranura 'mproc' de proc actual */ 

16208 EXTERN int dont_reply; /* normalmente 0; 1 p/inhibir respuesta */ 

16209 EXTERN int procs_in_use; /* cuántos procesos marcados IN_USE */ 

16210 

16211 /* Los parámetros de la llamada se guardan aquí. */ 

16212 EXTERN message mm_in;/* el mensaje entrante se guarda aquí. */ 

16213 EXTERN message mm_out; /* el mens. de respuesta se crea aquí. */ 

16214 EXTERN int who; /* núm. de proceso del invocador *1 

16215 EXTERN int mm_call; 1 * núm. de llamada al sistema *1 

16216 

16217 1 * Estas variables sirven para devolver resultados al invocador. *1 

16218 EXTERN int err_code; 1 * almac. temporal de núm. de error *1 

16219 EXTERN int result2; 1 * resultado secundario *1 

16220 EXTERN char *res_ptr; /* resultado, si apuntador *1 

16221 

16222 extern PROTOTYPE (int (*call_vec[ ]), (void) ); 1 * manej. de llamo al sist. *1 

16223 extern char core name[ ]; 1 * archivo donde se prado imág. núcleo *1 

16224 EXTERN sigset_t core_sset; 1 * qué señales causan imágenes de núcleo 





EL CÓDIGO FUENTE DE MINIX Archivo; src/mm/mproc.h 747 


src/mm/mproc.h 


16300 /* Esta tabla tiene 1 ranura p/proceso. Contiene toda la info. de admón. de memoria 

16301 * para cada proceso. Entre otras cosas, define los segmentos de texto, dato 

16302 * y. pila, uids y gids, y varias banderas. El kemel y FS 

16303 * tienen tablas indizadas también por proceso, y el contenido de las ranuras 

16304 * corresp. se refiere al mismo proceso en las tres. 

16305 */ 

16306 

16307 EXTERN struct mproc { 

16308 struct mem_map mp_seg[NR_S 

16309 char mp_exitstatus; 

16310 char mp_sigstatus; 

16311 pid_t mp_pid; 

16312 pid_t mp_procgrp; 

16313 pid t mp wpid; 

16314 int-mp_parent; 

16315 

16316 /* Uids y gids reales y efectivos 

16317 uid_t mp_realuid; 

16318 uid_t mp_effuid; 

16319 gid_t mp_realgid; 

16320 gid_t mp_effgid; 

16321 

16322 /* Identificación de archivo para compartir. */ 

16323 ino_t mp_ino; /* número de nodo-i del archivo */ 

16324 dev_t mp_dev; /* núm. de dispositivo del sist. archivos */ 

16325 time_t mp_ctime. /* nodo-i que cambió el tiempo */ 

16326 

16327 /* Información para manejo de señales 

16328 sigset_t mp_ignore; / 

16329 sigset_t mp_catch; / 

16330 sigset_t mp_sigmask; / 

16331 sigset_t mp_sigmask2; / 

16332 sigset_t mp_sigpending; / 

16333 struct sigaction mp_sigact[_NSIG + 1] 

16334 vir_bytes mp_sigretum; / 

16335 

16336 /* Compatibilidad hacia atrás para las señales. */ 

16337 sighandler_t mp_func; /* todas señales remito a 1 fcn usuario */ 

16338 

16339 unsigned mp_flags; /* bits de bandera */ 

16340 vir_bytes mp_procargs; /* apunt a args de pila inic de proc */ 

16341 } mproc [NR_PROCS]; 

16342 

16343 /* Valores de banderas */ 

16344 #defme INUSE 001 

16345 #define WAITING 002 

16346 #define HANGING 004 

16347 #define PAUSED 010 

16348 #define ALARMON 020 

16349 #define SEPARATE 040 

16350 #define TRACED 0100 

16351 #define STOPPED 0200 

16352 #defme SIGSUSPENDED 0400 

16353 

163 54 #defme NIL MPROC ((struct mproc *) 0) 


/* 1 si ranura 'mproc' en uso */ 

/* encend. por llamada siso WAIT */ 

/* encend. por llamada siso EXIT */ 

/* encend. por llamada siso PAUSE */ 

/* ene. al iniciarse tempor. SIGALRM */ 
/* 1 si arch. es espacio I & O separado */ 
/* 1 si el proceso debe rastrearse */ 

/* 1 si proc. detenido p/rastreo */ 

/* ene. por llamada siso SIGSUSPEND */ 


* 1 = ignorar señal, 0 = no */ 

* 1 = atrapar señal, 0 = no */ 

* señales que se bloquearán */ 

* copia guardada de mp_sigmask */ 

* señales que se bloquean */ 

; /* como en sigaction(2) */ 

* dir. de fuñe —sigretum de bibl. C */ 


íS] ;/* apunta a texto, datos, pila */ 

/* almac. p/situac. si proceso sale */ 

/* almac. p/núm. señal p/proc. matado */ 
/* id de proceso */ 

/* pid de grupo proc. (p/señales) */ 

/* pid que este proceso espera */ 

/* índice de proceso padre */ 


/* uid real del proceso */ 

/* uid efectivo del proceso */ 
/* gid real del proceso */ 

/* gid efectivo del proceso */ 
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16400 

/* Estos nombres s 

)n sinónimos de las 

variables del mensaje de entrada. */ 

16401 


#defme addr 

mm in.ml_pl 

16402 


#defme exec nan 

re mm in.ml_pl 

16403 


#defme exec len 

mm in.ml il 

16404 


#defme fuñe 

mm in.mó fl 

16405 


#defme grpid 

(gid t) mm in.ml il 

16406 


#defme namelen 

mm in.ml il 

16407 


#defme pid 

mm in.ml il 

16408 


#defme seconds 

mm in.ml il 

16409 


#defme sig 

mm in.mó il 

16410 


#defme stack bytes mm in.ml i2 

16411 


#defme stack_ptr 

mm in.ml_p2 

16412 


#define status 

mm in.ml il 

16413 


#defme usr id 

(uid t) mm in.ml il 

16414 


#defme request 

mm in.m2 i2 

16415 


#defme taddr 

mm in.m2 11 

16416 


#defíne data 

mm in.m2 12 

16417 


#defme sig nr 

mm in.ml i2 

16418 


#defme sig nsa 

mm in.ml_pl 

16419 


#defme sig osa 

mm in.ml_p2 

16420 


#defme sig_ret 

mm in.ml_p3 

16421 


#defme sig set 

mm in.m2 11 

16422 


#defme sig how 

mm in.m2 il 

16423 


#defme sig flags 

mm in.m2 i2 

16424 


#defme sig context mm in.m2_pl 

16425 

#ifdef SIGMESSAGE 



16426 


#defme sig msg 

mm in.ml il 

16427 

#endif 



16428 


#defme reboot flag mm in.ml il 

16429 

#defme reboot code 

fmm in.ml_pl 

16430 


#define reboot si 

ze mm in.ml i2 

16431 




16432 

/* Estos nombres s 

)n sinónimos de las 

variables del mensaje de salida. */ 

16433 


#defínereply type mm out.m type 

16434 


#defme replv il 

mm out.m2 il 

16435 


#defme reply_pl 

mm out.m2_pl 

16436 


#defme ret mask 

mm out.m2 11 

16437 




src/mm/table.c 


16500 /* Este archivo contiene la tabla que sirve para transformar los números de llama 

16501 * al sistema en las rutinas que las ejecutan. 

16502 */ 

16503 

16504 #define _TABl.fi 

16505 

16506 #include "mm.h" 

16507 #include <minix/callnr.h> 

16508 #include <signal.h> 

16509 #include "mproc.h" 
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16510 

#include "param.h" 





16511 






16512 

/* Diversos. */ 





16513 

char core_name[l = "core" 

/* archivo donde s 

prado imág. núcleo */ 


16514 






16515 

PROTOTYPE (int (*call_ 

veC 

[NCALLS]), 

(void)) = { 


16516 

no sys, / 


0 = no se usa 

*/ 


16517 

dommexit, / 


1 = exit 

*/ 


16518 

do_fork, / 


2 = fork 

*/ 


16519 

no_sys, / 


3 = read 

*/ 


16520 

no_sys, / 


4 = write 

*/ 


16521 

no_sys, / 


5 = open 

*/ 


16522 

no_sys, / 


6 = clase 

.*/ 


16523 

do_waitpid, / 


7 = wait 

*/ 


16524 

no_sys, / 


8 = creat 

*/ 


16525 

no_sys, / 


9 = link 

*/ 


16526 

no_sys, / 

10 

= unlink 

*/ 


16527 

do_waitpid, / 

11 

= waitpid 

*/ 


16528 

no_sys, / 

12 

= chdir 

*/ 


16529 

no_sys, / 

13 

= time 

*/ 


16530 

no_sys, / 

14 

= mknod 

*/ 


16531 

no_sys, / 

15 

= chmod 

*/ 


16532 

no_sys, / 

16 

= chown 

*/ 


16533 

do_brk, / 

17 

= break 

*/ 


16534 

no_sys, / 

18 

= stat 

*/ 


16535 

no_sys, / 

19 

= lseek 

*/ 


16536 

do_getset, / 

20 

= getpid 

*/ 


16537 

no_sys, / 

21 

= mount 

*/ 


16538 

no_sys, / 

22 

= umount 

*/ 


16539 

do_getset, / 

23 

= setuid 

*/ 


16540 

do_getset, / 

24 

= getuid 

*/ 


16541 

no_sys, /’ 

25 

= stime 

*/ 


16542 

do_trace, /’ 

26 

= ptrace 

*/ 


16543 

do_alarm, / : 

27 

= alarm 

*/ 


16544 

no_sys, /’ 

28 

= fstat 

*/ 


16545 

do_pause, 

*29 

= pause 

*/ 


16546 

no_sys, /’ 

*30 

= utime 

*/ 


16547 

no_sys, /* 

*31 

= (stty) 

*/ 


16548 

no_sys, / ! 

*32 

= (gtty) 

*/ 


16549 

no_sys, /’ 

*33 

= access 

*/ 


16550 

no_sys, /’ 

*34 

= (nice) 

*/ 


16551 

no_sys, /’ 

*35 

= (ftime) 

*/ 


16552 

no sys, /' 

*36 

= sync 

*/ 


16553 

do_kill, /= 

*37 

= kill 

*/ 


16554 

no sys, /’ 

*38 

= rename 

*/ 


16555 

no_sys, /’ 

*39 

= mkdir 

*/ 


16556 

no_sys, /’ 

*40 

= rmdir 

*/ 


16557 

no_sys, /’ 

*41 

= dup 

*/ 


16558 

no_sys, i 1 

*42 

= pipe 

*/ 


16559 

no_sys, /’ 

*43 

= times 

*/ 


16560 

no_sys, !'■ 

*44 

= (prof) 

*/ 


16561 

no_sys, / ! 

*45 

= no se usa 

*/ 


16562 

do_getset, /' 

*46 

= setgid 

*/ 


16563 

do_getset, /' 

*47 

= getgid 

*/ 


16564 

no_sys, /’ 

*48 

= (signal) 

*/ 


16565 

no_sys, I 1 

*49 

= no se usa 

*/ 


16566 

no_sys, / ! 

* 50 

= no se usa 

*/ 


16567 

no_sys, /'■ 

*51 

= (acct) 

*/ 


16568 

no_sys, /’ 

*52 

= (phys) 

*/ 


16569 

no_sys, /* 

: 53 = 

= (lock) 

*/ 
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16570 

16571 

16572 

16573 

16574 

16575 

16576 

16577 

16578 

16579 

16580 

16581 

16582 

16583 

16584 

16585 

16586 

16587 

16588 

16589 

16590 

16591 

16592 

16593 

16594 }; 


no_sys, 

no_sys, 

no_sys, 

no_sys, 

no_sys, 

doexec, 

no_sys, 

no_sys, 

do_getset, 

do_getset, 


7 * 54 = ioctl *7 

/* 55 = fcntl *7 

1* 56 = (mpx) *7 
1* 57 = no se usa *7 
1* 58 = no se usa *7 
1*59 = execve *1 
1* 60 = umask *1 
/ * 61 = chroot *1 
1*62 = setsid *1 
1*63 = getpgrp *1 


do_ksig, 

no_sys, 

no_sys, 

no_sys, 

no_sys, 

no_sys, 

no_sys, 

do_sigaction, 

do_sigsuspend, 

do_sigpending, 

do_sigprocmask, 

do_sigretum, 

doreboot, 


1 * 64 = KSIG: señales orig. en el kemel *1 

1*65 = UNPAUSE *1 

1* 66 = no se usa *1 

1 *61 = REVIVE *1 

7 * 68 = TASKREPLY *1 

1* 69 = no se usa *1 

1* 70 = no se usa *1 

1* 71 = sigaction *7 

1*12 = sigsuspend *1 

1*13 = sigpending *1 

1*14= sigprocmask *1 

7* 75 = sigretum *1 

1*16 = reboot *1 


src/mm/main.c. 


16600 7 * Este archivo contiene el prog. principal del adm. de memoria y algunos 

16601 * procedimientos relacionados. Cuando MINIX arranca, el kemel se ejecuta un rato, 

16602 * incializándose a sí mismo y a sus tareas, y luego ejecuta MM y FS. 

16603 * Ambos se inicial izan hasta donde pueden. Luego FS llama a MM porque MM 

16604 * debe esperar a que FS adquiera un disco en RAM. MM 

16605 * pide al kemel toda la memo libre y comienza a atender solicitudes. 

16606 * 

16607 * Los puntos de entrada a este archivo son: 

16608 * main: pone en marcha el MM 

16609* reply: responder a un proceso que efectúa llamada al sistema de MM 

16610 *1 

16611 

16612 #include "mm.h" 

16613 #include <minix/callnr.h> 

16614 #include <minix/com.h> 

16615 #include <signal.h> 

16616 #include <fcntl.h> 

16617 #include <sys/ioctl.h> 

16618 #include "mproc.h" 

16619 #include "param.h" 

16620 

16621 FORWARD PROTOTYPE( void get work, (void) ); 

16622 FORWARD PROTOTYPE ( void mmjni t, (void) ) ; 

16623 

16624 7*=============================================================: 
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16625 * main * 

16626 *============================= == =============== == =============*/ 

16627 PUBLIC void main() 

16628 { 

16629 /* Rutina principal del administrador de memoria. */ 

16630 

16631 interror; 

16632 

16633 mm_init(); /* inicializar tablas del administrador de memoria */ 

16634 

16635 /* Ciclo principal del MM- obtener trabajo y efectuarlo, eternamente. */ 

16636 while (TRUE) { 

16637 /* Esperar un mensaje. */ 

16638 get_work(); /* esperar llamada al sistema MM */ 

16639 mp = &mprOc [who]; 

16640 

16641 /* Izar algunas banderas. */ 

16642 error = OK; 

16643 dont_reply = FALSE; 

16644 err_code = -999; 

16645 

16646 /* Si núm. de llamada válido, ejecutar la llamada. */ 

16647 if (mmcall <011 mmcall >= NCALLS) 

16648 error = EBADCALL; 

16649 el se 

16650 error = (*call_vec[mm_Call]) (); 

16651 

16652 /* Devolver resultados al usuario p/indicar que terminamos. */ 

16653 if (dont_reply) continué; /* no resp. a EXIT ni WAIT */ 

16654 if (mm_call == EXEC && error = OK) continué; 

16655 reply(who, error, result2, res_ptr); 

16656 } 

16657 } 

16660 /*==== ==== == === == == ==== == == ====== === = =* 

16661 * get_work * 

16662 * = = = = = ===== = = = == == = === = == = ===== === === = = = = = === == = = = = == = = = = = = */ 

16663 PRIVATE void get_work() 

16664 { 

16665 /* Esperar sigte. mensaje y extraer información útil de él. */ 

16666 

16667 if (receive(ANY, &mm_in) != OK) panic("MM receive error", NO NUM); 

16668 who = mm_in.m_source; /* quién envió el mensaje */ 

16669 mm_call = mm_in.m_type; /* núm. de llamada al sistema */ 

16670 } 


16673 /*= 

16674 * 

16675 *= 

16676 

16677 

16678 

16679 

16680 
16681 
16682 
16683 


reply 


PUBLIC void reply(proc_nr, result, res2, respt) 

int proc_nr; /* proceso al cual responder */ 
int result; /* resultado de llamada (norm. OK o # error)*/ 

int res2; /* resultado secundario */ 

char *respt; /* resultado si apuntador */ 

{ 

/* Enviar una respuesta a un proceso de usuario. */ 


16684 register struct mproc *proc_ptr; 
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16685 

16686 proc_ptr = &mproc [proc_nr]j 

16687 /* 

16688 * Para hacer a MM robusto, ver si el destino sigue vivo. 

16689 * Debe omitirse esta verificación si el invocador es una tarea. 

16690 */ 

16691 if ((who >=0) && ((proc_ptr->mp_flags&IN_USE) = 011 

16692 (proc_ptr->mp_flags&HANGING») returnj 

16693 

16694 reply_type = result; 

16695 reply_il =res2; 

16696 reply_pl =respt; 

16697 if (send(proc_nr, &mm_out) 1= OK) panic("MM can't reply", NO_NUM); 

16698 } 

16701 /*=========================================================== 

16702 * mmjnit 

16703 *====================== = ======= = ============= == = 

16704 PRIVATE void mmJnitQ 

16705 { 

16706 /* Inicializar el administrador de memoria. */ 

16707 

16708 static char core_sigs[ ] = { 

16709 SIGQUIT, SIGILL, SIGTRAP, SIGABRT, 

16710 SIGEMT, SIGFPE, SIGUSR1, SIGSEGV, 

16711 SIGUSR2, 0}; 

16712 register int proc_nr; 

16713 register struct mproc *rmp; 

16714 register char * sig_ptr; 

16715 phys_clicks ram_clicks, total_clicks, minix_clicks, free_clicks, dummy; 

16716 messagemess; 

16717 shuct mem_map kemel_map[NR_SEGS]; 

16718 intmem; 

16719 

16720 /* Crear el conj. de señales que causan vaciados de núcleo. Hacerlo estilo Posix, 

16721 * así que no necesitamos conocer posiciones de bits. 

16722 */ 

16723 sigemptyset(&core_sset); 

16724 for (sig_ptr = core_sigs; *sig_ptr != 0; sig_ptr++) 

16725 sigaddset (&core_sset, *sig_ptr); 

16726 

16727 /* Obtener mapa de memoria del kemel para ver cuánta memoria usa, 

16728 * incluido el espacio entre la dir. 0 y el principio del kemel. 

16729 */ 

16730 sys_getmap(SYSTASK, kemel_map); 

16731 minix_clicks = kemel_map[S] ,mem_phys + kemel_map[S] ,mem_len; 

16732 

16733 /* Inicializar tablas del MM. */ 

16734 for (proc nr = 0; procnr <= INITPROCNR; proc_nr++) { 

16735 rmp = &mproc [proc_nr]; 

16736 rmp->mp_flags 1= INUSE; 

16737 sys_getmap(proc_nr, rmp->mp_seg); 

16738 if (rmp->mp_seg[T] .mem len != 0) rmp->mp_flags 1= SEPARATE; 

16739 minix_clicks += (rmp->mp_seg[S] ,mem_phys + rmp->mp_seg[S] ,mem_len) 

16740 -rmp->mp_seg[T] ,mem_phys; 

16741 } 

16742 mproc [INIT_PROC_NR] ,mp_pid = INIT PID; 

16743 sigemptyset(&mproc [INIT PROC NR] .mp ignore); 

16744 sigemptyset(&mproc[INIT_PROC_NR] .mp catch); 
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16745 procsjnuse = LOWJJSER + 1; 

16746 

16747 /* Esperar que FS envíe un mensaje con tamo de disco RAM y entre "en línea". 

16748 */ 

16749 if (receive(FS_PROC_NR, &mess) != OK) 

16750 panic("MM can’t obtain RAM disk size from FS", NO_NUM); 

16751 

16752 ram_clicks = mess.mljl; 

16753 

16754 /* Inicializar tablas a toda la memoria física. */ 

16755 mem_init(&total_clicks, &free_clicks); 

16756 

16757 /* Imprimir información de memoria. */ 

16758 printf("\nMemory size =%5dK ", click_to_round_k(total_clicks)); 

16759 printf("MINIX =%4dK ", click_to_round_k(minix_clicks)); 

16760 printf("RAM disk =%5dK ", click_to_round_k(ram_clicks)); 

16761 printf("Available =%5dK\n\n", click_to_round_k(free_clicks)); 

16762 

16763 /* Decir a FS que continúe. */ 

16764 if (send (FS_PROC_NR , &mess) != OK) 

16765 panic("MM can’t sync up with FS", NO_NUM); 

16766 

16767 /* Decir a la tarea de memo dónde está mi tabla de proc. para bien de ps(l). */ 

16768 if ((mem = open("/dev/mem", O RDWR)) !=-l){ 

16769 ioctl(mem, MIOCSPSINFO, (void *) mproc); 

16770 close(mem); 

16771 } 

16772 } 


src/mm/forkexit.c 


16800 /* Este archivo crea procesos (vía FORK) y los elimina (vía 

16801 * EXIT/WAIT). Si un proceso se bifurca, se le asigna una nueva ranura en la tabla 

16802 * 'mproc' y se hace 1 copia de la imagen de núcleo del padre piel hijo. 

16803 * Luego se informa al kemel y a FS. Se quita un proceso de 'mproc' 

16804* cuando ocurren dos eventos: (1) salió o se mató por una señal, y 
16805 * (2) el padre hizo un WAIT. S~ el proceso sale primero, sigue 
16806* ocupando su ranura hasta que el padre ejecuta WAIT. 

16807 * 

16808 * Los puntos de entrada a este archivo son: 

16809* do fork: realizar llamada al sistema FORK 

16810* do=mm_exit: realizar llamada al siso EXIT (invocando mm_exit(» 

16811* mm_exit: salir realmente 

16812* do wait: realizar llamadas al sistema WAITPID o WAIT 

16813 */ 

16814 

16815 

16816 

16817 

16818 

16819 

16820 
16821 
16822 

16823 

16824 


#include "mm.h" 

#include <sys/wait.h> 

#include <minix/callnr.h> 

#include <signal.h> 

#include "mproc.h" 

#include "param.h" 

#define LAST_FEW 2 /* últ. ranuras reservadas p/superusuario */ 
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16825 PRIVATE pid_t next_pid = INIT_PID+1; /* sigte. pid por asignar */ 

16826 

16827 FORWARD PROTOTYPE (void cleanup, (register struct mproc *child)); 

16828 

16829 /♦================= = ================= = ======= = ====== 

16830 * do_fork 

16831. ♦== == = ===== ==== ========= = ====== 

16832 PUBLIC int do_fork() 

16833 { 

16834 /* El proceso al que apunta ’mp' bifurcó. Crear un proceso hijo. */ 

16835 

16836 register struct mproc *rmp; /* apuntador al padre */ 

16837 register struct mproc *rmc; /* apuntador al hijo */ 

16838 int i, child_nr, t; 

16839 phys_clicks prog_clicks, child_base = 0; 

16840 phys_bytes prog_bytes, parent_abs, child_abs; /* Sólo Intel */ 

16841 

16842 /* Si las tablas podrían llenarse durante FORK, ni siquiera comenzar 

16843 * porque recuperarse a medio camino es una lata. 

16844 */ 

16845 rmp = mp; 

16846 if (procsjnuse = NR PROCS) retum(EAGAIN); 

16847 if (procsjnuse >= NR PROCS-LAST FEW && rmp->mp_effuid != O)retum(EAGAIN); 

16848 

16849 /* Determinar cuánta memoria repartir. Sólo hay que copiar datos y pila, 

16850 * porque el segmento de texto es compartido o de longitud cero. 

16851 */ 

16852 prog_clicks = (phys_clicks) rmp->mp_seg[S] ,mem_len; 

16853 prog_clicks += (rmp->mp_seg[S] .memvir -rmp->mp_seg[D] .memvir); 

16854 prog_bytes = (phys_bytes) prog_clicks « CLICK_SHIFT; 

16855 if ( (child_base = alloc_mem(prog_clicks)) == NO_MEM) retum(EAGAIN); 

16856 

16857 /* Crear copia de la imagen de núcleo del padre para el hijo. */ 

16858 child_abs = (phys_bytes) child_base « CLICK_SHIFT; 

16859 parent abs = (phys_bytes) rmp->mp_seg[D] ,mem_phys « CLICKSHIFT; 

16860 i = sys_copy(ABS, 0, parent abs, ABS, 0, child abs, progbytes); 

16861 if (i < 0) panic("do_fork can't copy", i); 

16862 

16863 /* Encontrar ranura en 'mproc' para el hijo. Debe haber una. */ 

16864 for (rmc = &mproc[0]; rmc < &mproc[NR_PROCS]; rmc++) 

16865 if ( (rmc->mp flags & IN USE) = 0) break; 

16866 

16867 /* Preparar hijo y su mapa de memoria; copiar su ranura 'mproc' del padre. */ 

16868 child_nr = (int) (rmc-mproc); /* núm. ranura del hijo */ 

16869 procs_in_use++; 

16870 *rmc = *rmp; /* copiar ranura de proc de padre ahijó */ 

16871 

16872 rmc->mp_parent = who; /* registrar padre del hijo */ 

16873 rmc->mp_flags &= -TRACED; /* hijo no hereda situac. de rastreo */ 

16874 /* Un hijo con I&D separada conserva el segmento de texto del padre. 

16875 * Los segmentos de datos y pila deben hacer reto a la nueva copia. 

16876 */ 

16877 if (! (rmc->mp~flags & SEPARATE)) rmc->mp_seg[T] ,mem_phys = child base; 

16878 rmc->mp_seg[D] ,mem_phys = child base; 

16879 rmc->mp_seg[S] ,mem_phys = rmc->mp_seg[D] ,mem_phys + 

16880 (rmp->mp_seg[S] .mem vir -rmp->mp_seg[D] .mem vir); 

16881 rmc->mp_exitstatus = 0; 

16882 rmc->mp_sigstatus = 0; 

16883 

16884 /* Encontrar pid libre para el hijo y ponerlo en la tabla. */ 
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16885 do { 

16886 t = 0; /*’t'= 0 indica pid aún libre */ 

16887 next_pid = (next_pid < 30000 ? next_pid + 1 : INIT_PID + 1); 

16888 for (rmp = &mproc[01j rmp < &mproc[NR_PROCS]; rmp++) 

16889 if (rmp->mp_pid = next_pid 11 rmp->mp_procgrp = next_pid) { 

16890 t = 1; 

16891 break; 

16892 } 

16893 rmc->mp_pid = next_pid; /* asignar pid al hijo */ 

16894 } while (t); 

16895 

16896 /* Decir a kemel y FS acerca del FORK (que ya tuvo éxito). */ 

16897 sys_fork(who, child_nr, rmc->mp_pid, child_base)j /* child_base es sólo 68K*/ 

16898 tell_fs(FORK, who, child_nr, rmc->mp_pid); 

16899 

16900 /* Informar al kemel el mapa de memoria del hijo. */ 

16901 sys_newmap(child_nr, rmc->mp_seg); 

16902 

16903 /* Contestar al hijo para despertarlo. */ 

16904 reply(child_nr, 0, 0, NILPTR); 

16905 retum(next_pid); /* pid del hijo */ 

16906 } 


16909 /*===== === ==== = = ====== = == == 

16910* dommexit 

16911 *== = == = ========= = == = ====== = ========== = == = === = == ====== ==== 

16912 PUBLIC int do_mm_exit() 

16913 { 

16914 /* Realizar llamada exit(status). El trabajo real lo efectúa mm_exit(), 

16915 * que también se invoca cuando un proceso se mata por una señal. 

16916 */ 

16917 

16918 mm_exit(mp, status); 

16919 dont_reply = TRUEj /* no resp. a proceso recién terminado */ 

16920 retum(ÓK); /* código de retomo pro forma */ 

16921 } 




16924 /*===== = = = = == = = = = ===== = = === = = = = = == = = = == = == = == = = = ===== = = = = =* 

16925 * mm exit * 

16926 *== = ================== = ===== = = = === = = = == = ===== = === = = === */ 

16927 PUBLIC void mm_exit(rmp, exit status) 

16928 register struct mproc *rmp;/* apunto al proceso por terminar */ 

16929 int exit_status; /* situac. de salida del proceso (p/padre) */ 

16930 { 

16931 /* Un proceso terminó. Liberar casi todas sus posesiones. 

16932 * Si su padre está esperando, liberar el resto, si no, suspender. 

16933 */ 

16934 

16935 register int proc_nr; 

16936 int parent_waiting, right_child; 

16937 pid_t pidarg, procgrp; 

16938 phys_clicks base, size, s; /* base y tamaño sólo en 68000 */ 

16939 

16940 proc_nr = (int) (rmp -mproc); /* obtener núm. ranura del proceso */ 

16941 

16942 /* Recordar grupo de procesos de un jefe de sesión. */ 

16943 procgrp = (rmp->mp_pid == mp->mp_procgrp) ? mp->mp_procgrp : 0; 

16944 
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16945 /* Si el proc que salió tenía temporiz. pendiente, matarlo. */ 

16946 if (rmp->mp_flags & ALARM_ON) set_alarm(proc_nr, (unsigned) 0); 

16947 

16948 /* Decir a kemel y FS que el proceso ya no es ejecutable. */ 

16949 tell_fs(EXIT, proc_nr, 0, 0); /* FS puede liberar ranura de proc */ 

16950 sys_xit(rmp->mp_parent, proc_nr, &base, &size); 

16951 

16952 /* Liberar la memoria ocupada por el hijo. */ 

16953 if (fmd_share(rmp, rmp->mp_ino, rmp->mp_dev, rmp->mp_ctime) = NULL) { 

16954 /* Ningún otro proceso comparte el segmento de texto, así que liberar. */ 

16955 free_mem(rmp->mp_seg[T] ,mem_phys, rmp->mp_seg[T] .mem len); 

16956 ¡ 

16957 /* Liberar los segmentos de datos y de pila. */ 

16958 free mem(rmp->mp seg[D].mem phys, 

16959 rmp->mp_seg[S] .mem vir + rmp->mp_seg[S].mem_len -rmp->mp_seg[D] .mem virjj 

16960 

16961 /* Sólo puede liberarse la ranura si el padre ejecutó WAIT. */ 

16962 rmp->mp_exitstatus = (char) exit_status; 

16963 pidarg = mproc[rmp->mp_parent] ,mp_wpid; /* ¿a quién esperan? */ 

16964 parent_waiting = mproc[rmp->mp_parent].mp_flags & WAITING; 

16965 if (pidarg = -1 | | pidarg = rmp->mp_pid | | -pidarg = rmp->mp_procgrp) 

16966 right_child = TRUE; /* hijo pasa una de 3 pruebas */ 

16967 else 

16968 right_child = FALSE; /* hijo falla las 3 pruebas */ 

16969 if (parent_waiting && right_child) 

16970 cleanup(rmp); /* decir a padre y lib. ranura hijo */ 

16971 else 

16972 rmp->mp_flags 1= HANGING; /* padre no espera, suspender hijo */ 

16973 

16974 /* Si el proc tiene hijos, desheredarlos. INIT es el nuevo padre. */ 

16975 for (rmp = &mproc[0]; rmp < &mprOc[NR_PROCS]; rmp++) { 

16976 if (rmp->mp_flags & IN_USE && rmp->mp_parent = proc_nr) { 

16977 /* ahora 'rmp' apunta a un hijo para desheredarlo. */ 

16978 rmp->mp_parent = INITPROCNR; 

16979 parent waiting = mproC[INIT_PROC_NR}.mp flags & WAITINGj 

16980 if (parent_waiting && (rmp->mp_flags & HANGING)) cleanup(rmp)j 

16981 } 

16982 } 

16983 

16984 /* Enviar susp. al gpo. de procs. del proceso si era jefe de sesión. */ 

16985 if (procgrp != 0) check_sig(-procgrp, SIGHUP); 

16986 } 

16989 /*===== === ====== == ==== == = === = == = == =* 

16990 * do_waitpid * 

16991 *======= = ================= = = - --======================= == =============*/ 

16992 PUBLIC int do_waitpid() 

16993 { 

16994 /* Un proceso quiere esperar que un hijo termine. Si uno ya está esperando, 

16995 * asearlo y dejar que termine esta llamada WAIT. Si no, esperar realmente. 

16996 * Este código maneja tanto WAIT como WAITPID. 

16997 */ 

16998 

16999 register struct mproc *rp; 

17000 int pidarg, options, children, res2; 

17001 

17002 /* Un proceso que invoca WAIT nunca recibe una respuesta normal 

17003 * vía reply() en el ciclo principal (a menos que esté izada WNOHANG 

17004 * o no haya un hijo que califique). Si un hijo ya salió, la rutina cleanup( ) 
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17005 * envía la respuesta para despertar al invocador. 

17006 */ 

17007 

17008 /* Fijar variables internas, dependiendo de si es WAIT o WAITPID. */ 

17009 pidarg = (mm call = WAIT ?-1 : pid); /* ler. parám de waitpid */ 

17010 options = (mm_call = WAIT? 0: sig_nr); /* 3er. parám de waitpid */ 

17011 if (.pidarg == 0) pidarg = -mp->mp_procgrp; /* pidarg < 0 ==> gpo proc */ 

17012 

17013 /* ¿Hay un hijo que espere ser recogido? Aquí, pidarg != 0: 

17014 * pidarg > 0 indica pidarg es pid de un proc dado al cual esperar 

17015 * pidarg —-1 indica esperar cualquier hijo 

17016 * pidarg < -1 indica esperar cualq. hijo cuyo gpo. proc = -pidarg 

17017 */ 


17018 

17019 

17020 

17021 

17022 

17023 

17024 

17025 

17026 

17027 

17028 

17029 

17030 

17031 

17032 

17033 

17034 

17035 

17036 

17037 

17038 

17039 

17040 

17041 

17042 

17043 

17044 

17045 

17046 

17047 

17048 

17049 

17050 

17051 

17052 

17053 

17054 

17055 


children = 0; 

for (rp = &mproc[0] j rp < &mproc[NR_PROCSlj rp++) { 

if ( (rp->mp_flags & IN_USE) && rp->mp_parent — who) { 

/* El valor de pidarg determina cuáles hijos califican. */ 
if (pidarg > 0 && pidarg != rp->mp_pid) continué; 
if (pidarg < -1 && -pidarg != rp->mp_procgrp) continué; 

children++; /* este hijo es aceptable */ 

if (rp->mp_flags & HANGING) { 

/* Este hijo pasó prueba de pid y salió. */ 
cleanup(rp); /* este hijo ya salió */ 

dont_reply = TRUE; 
retum(OK); 

} 

if ((rp->mp_flags & STOPPED) && rp->mp_sigstatus) { 

/* Este hijo pasó prueba pid y se rastrea.*/ 
res2 = 0177 1 (rp->mp_sigstatus« 8); 

reply(who, rp->mp_pid, res2, NILPTR); 
dont_reply = TRUE; 
rp->mp_sigstatus = 0; 
retum(OK); 

} 


/* No salió ningún hijo que califique. Esperar uno, si existe. */ 
if (children > 0) { 

/* Existe al menos 1 hijo que pasa prueba pid, pero no ha salido. " 


if (options & WNOHANG) retum(O); 
mp->mp_flags 1=WAITING; 
mp->mp_wpid = (pid t) pidarg; 
dont_reply = TRUE; 
retum(OK); 


/* Ningún hijo pas 
retum(ECHILD); 


prueba pido Devolver ei 


/* padre no quiere esperar */ 
/* padre quiere esperar */ 

/* guardar pid p/después */ 

/* pero no responder ahora */ 
/* sí -esperar que uno salga */ 

ar de inmediato. */ 

/* no -padre no tiene hijos */ 


17058 /*===== === === === = == ==== 

17059* clearlup 

17060 *====================== = === == = == ======= 

17061 PRIVATE void cleanup(child) 

17062 register struct mproc *child; 

17063 { 

17064 /* Terminar salida de un proc. El proceso salió o se mató por 


========—*/ 

/* dice cuál proceso está saliendo */ 
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17065 * una señal, y su padre está esperando. 

17066 */ 

17067 

17068 int exitstatus; 

17069 

17070 /* Despertar al padre. */ 

17071 exitstatus = (child->mp_exitstatus « 8) I (child->mp_sigstatus & 0377); 

17072 reply(child->mp_parent, child->mp_pid, exitstatus, NIL_PTR); 

17073 mproc[child->mp_parent] ,mp_flags &= -WAITING; /* padre ya no espera */ 

17074 

17075 /* Liberar la entrada de tabla del proceso. */ 

17076 child->mp_flags = 0; 

17077 procs_in_use-; 

17078 } 



17100 /* Este archivo maneja la llamada al sistema EXEC, y trabaja como sigue: 

17101 * -ver si los permisos indican que el archivo se puede ejecutar 

17102 * -leer la cabecera y extraer los tamaños 

17103 * -traer argumentos iniciales y entorno del espacio de usuario 

17104 * -asignar la memoria para el nuevo proceso 

17105 * -copiar pila inicial de MM al proceso 

17106 * -leer de disco segmentos de texto y datos y copiar en proceso 

17107 * -ajustar bits de setuid y setgid 

17108* -arreglar tabla ’mproc' 

17109* -decir al kemel del EXEC 

17110 * -guardar distancia a argc inicial (para ps) 

17111 * 

17112 * Los puntos de entrada a este archivo son: 

17113* do exec: realizar la llamada al sistema EXEC 

17114 * fmd_share: encontrar proceso cuyo segm. de texto pueda compartirse 

17115 */ 

17116 

17117 #include "mm.h" 

17118 #include <sys/stat.h> 

17119 #include <minix/callnr.h> 

17120 #include <a.out.h> 

17121 #include <signal.h> 

17122 #include <string.h> 

17123 #include "mproc.h" 

17124 #include "param.h" 

17125 

17126 FORWARD _PROTOTYPE( void load seg, (int fd, int seg, vir bytes seg_bytes)); 

17127 FORWARD _PROTOTYPE( int new mem, (struct mproc *sh_mp, vir bytes text bytes, 

17128 vir_bytes data_bytes, vir_bytes bss_bytes, 

17129 vir_bytes stk_bytes, phys_bytes tot_bytes) ); 

17130 FORWARD _PROTOTYPE( void patch ptr, (char stack [ARG MAX ], vir bytes base)); 

17131 FORWARD _PROTOTYPE( int read_header, (int fd, int *ft, vir_bytes *text_bytes, 

17132 vir_bytes *data_bytes, vir_bytes *bss_bytes, 

17133 phys_bytes *tot_bytes, long *sym_bytes, vir_clicks se, 

17134 vir_bytes *pc) ); 

17135 

17136 

17137 /*============================================= = ========= 

17138 * doexec * 

17139 *======= = =============== = ========================= == ====== == 
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17140 PUBLIC int do_exec() 

17141 { 

17142 /* Ejecutar llamada execve(name, argv, envp). La biblioteca de usuario 

17143 * construye una imagen de pila completa, incl. apuntadores, args, entorno, etc. 

17144 * La pila se copia en un buffer dentro de MM, y luego a la nueva imagen de núcleo. 

17145 */ 

17146 

17147 register struct mproc *rmp; 

17148 struct mproc * sh_mp; 

17149 int m, r, fd, ft, sn; 

17150 static char mbufjARGMAX]; /* buffer para pila y ceros */ 

17151 static char name_buf[PATH_MAX]; /* archivo por ejecutar */ 

17152 char *new_sp, *basename; 

17153 vir_bytes src, dst, text_bytes, data_bytes, bss_bytes, stk_bytes, vsp; 

17154 phys_bytes tot_bytes; /* espacio total p/programa, incl. espacio */ 

17155 long sym_bytes; 

17156 vir_clicks se; 

17157 struct stat s_buf; 

17158 vir_bytespc; 

17159 

17160 /* Realizar algunas comprobaciones de validez. */ 

17161 rmp = mp; 

17162 stk_bytes = (vir_bytes) stack_bytes; 

17163 if (stk bytes > ARG_MAX) retum(ENOMEM); /* pila demasiado grande */ 

17164 if (execjen <=011 execjen > PATH MAX) retum(EINVAL); 

17165 

17166 /* Obtener nombre de arch. por ejecutar y ver si es ejecutable. */ 

17167 src = (vir_bytes) exec_name; 

17168 dst = (vir_bytes) name_buf; 

17169 r = sys_copy(who, D, (phys_bytes) src, 

17170 MM PROC NR, D, (phys_bytes) dst, (phys_bytes) execjen); 

17171 if (r != OK) retum(r); /* nombre arch no en segm datos usuario */ 

17172 tell fs(CHDIR, who, FALSE, 0); /* cambiar a entorno FS usuario. */ 

17173 fd =-allOwed(name_buf, &s_buf, X_BIT); /* ¿archivo ejecutable? */ 

17174 if (fd < 0) retum(fd); /* el archivo no era ejecutable */ 

17175 

17176 /* Leer cabecera del archivo y extraer tamaños de segmentos. */ 

17177 se = (stk bytes + CLICK SIZE -1) » CLICK_SHIFT; 

17178 m = read_header(fd, &ft, &textj>ytes, &dataj>ytes, &bssj>ytes, 

17179 &tot_bytes, &sym_bytes, se, &pc); 

17180 if (m < 0) { 

17181 close(fd); /* algo está mal en la cabecera */ 

17182 retum(ENOEXEC); 

17183 } 

17184 

17185 /* Traer la pila del usuario antes de destruir imagen de núcleo vieja. */ 

17186 src = (vir_bytes) stack_ptr; 

17187 dst = (vir J>ytes) mbuf; 

17188 r = sys_copy(who, D, (phys_bytes) src, 

17189 MM_PROCJSÍR, D, (phys_bytes) dst, (phys_bytes)stk_bytes); 

17190 if(r != OK) { 

17191 close(fd); /* imposible traer pila (p.ej. dir. virtual mala) */ 

17192 retum(EACCES); 

17193 } 

17194 

17195 /* ¿Texto del proc puede compartirse con el de uno ya en ejecución? */ 

17196 sh_mp = fmd_share(rmp, s_buf.st_ino, s_buf.st_dev, s_buf.st_ctime); 

17197 

17198 /* Asignar nueva memoria y liberar vieja. Arreglar mapa y decir al kemel. */ 

17199 r = new_mem(sh_mp, text_bytes, data_bytes, bss_bytes, stk_bytes, tot_bytes); 
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17200 if(r!=OK){ 

17201 close(fd); /* núcleo insuf. o prog demasiado grande */ 

17202 retum(r); 

17203 } 

17204 

17205 /* Guardar identificación del archivo pique pueda compartirse. */ 

17206 rmp->mp_ino = s_buf.st_ino; 

17207 rmp->mp_dev = s_buf.st_dev; 

17208 rmp->mp_ctime = s_buf.st_ctime; 

17209 

17210 /* Parchar pila y copiarla de MM a nueva imagen de núcleo. */ 

17211 vsp = (virbytes) rmp->mp_seg[S] ,mem_vir « CLICK_SHIFT; 

17212 vsp+= (vir bytes) rmp->mp_seg[S] .mem len « CLICKSHIFT; 

17213 vsp -= stk bytes; 

17214 patch_ptr(mbuf, vsp); 

17215 src = (vir_bytes) mbuf; 

17216 r = sys_copy(MM_PROC_NR, D, (phys bytes) src, 

17217 who, D, (phys_bytes) vsp, (phys_bytes)stk_bytes); 

17218 if (r != OK) panic("do_exec stack copy err", NOJSÍUM); 

17219 

17220 /* Leer de disco segmentos de texto y datos. */ 

17221 if (sh mp 1= NULL) { 

17222 lseek(fd, (off_t) text_bytes, SEEK_CUR); /* compartido: omitir texto */ 

17223 | el se ¡ 

17224 load_seg(fd, T, text_bytes); 

17225 } 

17226 load_seg(fd, D, data_bytes); 

17227 

17228 

17229 close(fd); /* ya no se necesita arch. ejec. */ 

17230 

17231 /* Cuidado con bits setuid/setgid. */ 

17232 if ((rmp->mp_flags & TRACED) = 0) { /* suprimir si rastreando */ 

17233 if (s_buf.st_mode & I SET UID 8IT) { 

17234 rmp->mp_effiiid = s_buf.st_uid; 

17235 tell_fs(SETUID,who, (int)rmp->mp_realuid, (int)rmp->mp_effuid); 

17236 } 

17237 if (s_buf.st_mode & I SET GID BIT) { 

17238 rmp->mp_effgid = s_buf.st_gid; 

17239 tell_fs(SETGID,who, (int)rmp->mp_realgid, (int)rmp->mp_effgid); 

17240 | 

17241 } 

17242 

17243 /* Guardar distancia a argc inicial (para ps) */ 

17244 rmp->mp_procargs = vsp; 

17245 

17246 /* Arreglar campos ’mproc', decir kemel exec terminó, reset atrapó señ. */ 

17247 for (sn = lj sn <= _NSIGj sn++) { 

17248 if (sigismember(&rmp->mp_catch, sn)) { 

17249 sigdelset(&rmp->mp_catch, sn); 

17250 rmp->mp_sigact[sn] ,sa_handler = SIG_DFL; 

17251 sigemptyset(&rmp->mp_sigact[sn] ,sa_mask); 

17252 } 

17253 } 

17254 

17255 rmp->mp_flags &=-SEPARATE; /* apagar bit SEPARATE */ 

17256 rmp->mp_flags 1= ft; /* activar si archivos 1 & D separados */ 

17257 new_sp = (char *) vsp; 

17258 

17259 tell_fs(EXEC, who, 0, 0); /* que FS maneje archivos FD CLOEXEC */ 
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17260 

17261 /* Sistema guardará linea comandos p/depurac., salida ps(l), etc. */ 

17262 basename = strrchr(name_buf, 'I'); 

17263 if (basename = NULL) basen ame = name_buf; else basename++; 

17264 sys_exec(who, new_sp, rmp->mp_flags & TRACED, basename, pe); 

17265 retum(OK); 

17266 } 


17269 / 

17270 

17271 ! 

17272 

17273 

17274 

17275 

17276 

17277 

17278 

17279 

17280 

17281 

17282 

17283 

17284 

17285 

17286 

17287 

17288 

17289 

17290 

17291 

17292 

17293 

17294 

17295 

17296 

17297 

17298 

17299 

17300 

17301 

17302 

17303 

17304 

17305 

17306 

17307 

17308 

17309 

17310 

17311 

17312 

17313 

17314 

17315 

17316 

17317 

17318 

17319 


read_header 


PRIVATE int read_header(fd, ft, text_bytes, data_bytes, bss_bytes, 

tot_bytes, sym_bytes, se 

fd; /* dése, archivo p/leer archivo ejec. */ 

ít *ft; /* lugar p/devolver ni 


vir_bytes *text_bytes; 
vir_bytes *data_bytes; 
vir_bytes *bss_bytes; 
phys_bytes *tot_bytes; 
long *sym_bytes; 
vir_clicks se; 
vir bytes *pC; 


lugar p/devolver tamaño texto */ 

/* lugar p/devolver tamo datos inicial. * 
/* lugar p/devolver tamaño bss */ 

/* lugar p/devolver tamaño total */ 

/* lugar p/devolver tamo tabla símb. * 1 
/* tamaño de pila en clics */ 

/* punto entrada programa (PC inicial) */ 


/* Leer cabecera y extraer tamaños texto, datos, bss y total. */ 


vir_clicks te, de, s_vir, dvir; 
phys_clicks tote; 

struct exec hdr; /* aquí se lee cabecera a.out */ 

/* Leer cabecera y verificar el número mágico. La cabecera MINIX 

* estándar se define en <a.out.h> y consiste en 8 chars seguidos por 6 longs; 

* luego vienen 4 long s más que no se usan aquí. 

* Byte 0: número mágico 0x01 

* Byte 1: número mágico 0x03 

* Byte 2: normal = 0x10 (no verif, 0 es OK) l/D separado = 0x20 

* Byte 3: Tipo CPU, Intel 16 bits = 0x04, Intel 32 bits = 0x10, 

* Motorola = OxOB, Sun SPARC = 0x17 

* Byte 4: Longitud de cabecera = 0x20 

* Bytes 5-7 no se usan. 

* Ahora vienen los 6 longs 

* Bytes 8-11: tamaño de segmentos de texto en bytes 

* Bytes 12-15: tamaño de segm. de datos inicializado en bytes 

* Bytes 16-19: tamaño de bss en bytes 

* Bytes 20-23: punto de entrada al programa 

* Bytes 24-27: memo total asignada al programa (texto, datos + pila) 

* Bytes 28-31: tamaño de tabla de símbolos en bytes 

* Los longs se representan en un orden que depende de la máquina, 

* little-endian en el 8088, big-endian en el 68000. 

* La cabecera va seguida directamente de los segmentos de texto y 

* datos, y la tabla de símbolos (en su caso). Los tamaños se dan en 

* la cabecera. Exec s610 copia los segmentos de texto y datos en la 

* memoria. La cabecera se usa s610 aquí. La tabla de símbolos s610 

* sirve a un depurador y se hace caso omiso de ella aquí. 


if (read(fd, (char *) &hdr, AMINHDR) 1= AMINHDR) retum(ENOEXEC); 
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17320 1 * Verificar número mágico, tipo de cpu y banderas. *1 

17321 if (BADMAG(hdr)) retum(ENOEXEC); 

17322 #if (CHIP == INTEL && WORDSIZE = 2) 

17323 if (hdr.a_cpu 1= AI8086) retum(ENOEXEC); 

17324 #endif 

17325 #if (CHIP == INTEL && WORDSIZE = 4) 

17326 if (hdr.a_cpu != A I80386) retum(ENOEXEC); 

17327 #endif 

17328 if ((hdr.ajlags & -(A NSYMIA EXEC IASEP)) != 0) retum(ENOEXEC); 

17329 

17330 *ft = ( (hdr.a_flags & A SEP) ? SEPARATE : 0); 1 * I & O separado o no *1 

17331 

17332 1 * Obtener tamaños de texto y datos. *1 

17333 *text_bytes = (vir_bytes) hdr.a_text; 1 * tamaño texto en bytes *1 

17334 *data_bytes = (vir_bytes) hdr.a_data; 1 * tamaño datos en bytes *1 

17335 *bss_bytes = (vir_bytes) hdr.a_bss; 1 * tamaño de bss en bytes *1 

17336 *tot_bytes = hdr.a_total; 1 * total bytes asigo al programa *1 

17337 *sym_bytes = hdr.a_syms; 1 * tamo tabla símb. en bytes *1 

17338 if (*tot_bytes == 0) retum(ENOEXEC); 

17339 

17340 if (*ft 1= SEPARATE) { 

17341 

17342 1 * Si espacio I & O no separado, todo se considera datos. Text=0*l 

17343 *data_bytes += *text_bytes; 

17344 *text_bytes = 0; 

17345 

17346 } 

17347 *pc = hdr.a_entry; 1 * dirección p/iniciar ejecución *1 

17348 

17349 1 * Ver si los tamaños de segmento son factibles. *1 

17350 te = ((unsigned long) *text_bytes + CLICKSIZE -1) » CLICKSHIFT; 

17351 de = (*data_bytes + *bss_bytes + CLICK SIZE -1) » CLICK SHIFT; 

17352 tote = (*tot_bytes + CLICK SIZE -1) » CLICK SHIFT; 

17353 if (de >= tote) retum(ENOEXEC); 1 * pila debe ser al menos 1 clic *1 

17354 dvir = (*ft = SEPARATE? 0: te); 

17355 s_vir = dvir + (tote -se); 

17356 m = size_ok(*ft, te, de, se, dvir, s_vir); 

17357 ct = hdr.a_hdrlen & BYTE; 1 * longitud de cabecera *1 

17358 if (ct > A MINHDR) lseek(fd, (off_t) ct, SEEK SET); 1* saltar cab no usada *1 

17359 retum(m); 

17360 } 


17363 1*==================================================== 

17364 * new mem 

17365 *===================================================== 

17366PRIVATE int new_mem(sh_mp, text_bytes, data_bytes,bss_bytes,stk_bytes,tot_bytes] 

17367 stmet mproc *sh_mp; 1 * puede compartirse texto con este proc *1 

17368 vir_bytes text_bytes; 1 * tamaño segmento de texto en bytes *1 

17369vir_bytes data_bytes; 1 * tamaño datos inicializ. en bytes *1 

17370vir_bytes bss_bytes; 1 * tamaño de bss en bytes *1 

17371 vir_bytes stk_bytes; 1 * tamo segm. pila inicial en bytes *1 

17372phys_bytes tot_bytes; 1 * memo total p/asignar, incl. espacio *1 

17373 { 

17374 1* Asignar memoria nueva y liberar vieja. Cambiar mapa e informar nuevo mapa al 

17375 * kemel. Poner en 0 bss, espacio y pila de nueva imagen núcleo. 

17376 *1 

mu 

17378 register struct mproc *rmp; 

17379 vir_clicks text_clicks, data_clicks, gap_clicks, stack_clicks, tot_clicks; 
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17380 phys_clicks new_base; 

17381 

17382 static char zero[1024]; /* para poner en cero bss */ 

17383 phys_bytes bytes, base, count, bss_offset; 

17384 

17385 /* No es necesario asignar texto si se puede compartir. */ 

17386 if (sh_mp != NULL) text_bytes = 0; 

17387 

17388 /* Adquirir la nueva memoria; c/u de las 4 partes: texto, (datos+bss), 

17389 * espacio y pila ocupa núm. entero de clics, comenzando en frontera de clic. 

17390 * Las partes de datos y bss se juntan sin espacio. 

17391 */ 

17392 

17393 text_clicks = ((unsigned long) text_bytes + CLICKSIZE -1) » CLICKSHIFT; 

17394 data_clicks = (data_bytes + bss_bytes + CLICK SIZE -1) » CLICK SHIFT; 

17395 stack clicks = (stk bytes + CLICK SIZE -1) » CLICK SHIFT; 

17396 tot clicks = (tot bytes + CLICK SIZE -1) » CLICK SHIFT; 

17397 gap_clicks = tot_clicks -data_clicks -stack_clicks; 

17398 if ( (int) gap_clicks < 0) retum(ENOMEM); 

17399 

17400 /* Ver si hay un agujero de tamaño suficiente. Si lo hay, podemos arriesgar 

17401 * a liberar primero la vieja imagen de núcleo antes de asignar la nueva, 

17402 * pues sabemos que se podrá. Si no hay suficiente, devolver fracaso. 

17403 */ 

17404 if (text_clicks + tot_clicks > max_hole()) retum(EAGAIN); 

17405 

17406 /* Hay sufic. memoria para nueva imagen núcleo. Liberar la vieja. */ 

17407 rmp = mp; 

17408 

17409 if (fmd_share(rmp, rmp->mp_ino, rmp->mp_dev, rmp->mp_ctime) = NULL) { 

17410 /* Ningún otro proc. comparte segmento de texto, así que liberarlo. */ 

17411 free_mem(rmp->mp_seg[T] ,mem_phys, rmp->mp_seg[T] .mem len); 

17412 } 

17413 /* Liberar segmentos de datos y de pila. */ 

17414 free_mem(rmp->mp_seg[D] ,mem_phys, 

17415 rmp->mp_seg[S] .memvir + rmp->mp_seg[S] .mem len -rmp->mp_seg[D] .mem_\ 

17416 

17417 /* Ya no podemos echamos atrás. Perdimos para siempre la imagen vieja. 

17418 * La llamada debe llegar al final. Preparar e informar nuevo mapa. 

17419 */ 

17420 new_base = alloc_mem(text_clicks + tot_clícks); /* nueva imagen de núcleo */ 

17421 if (new_base = NO_MEM) panic("MM hole list is inconsístent", NO NUM); 

17422 

17423 if (sh_mp !=NULL) { 

17424 /* Compartir segmento de texto. */ 

17425 rmp->mp_seg[T] = sh_mp->mp_seg[T]; 

17426 } else { 

17427 rmp->mp_seg[T] ,mem_phys = new_base; 

17428 rmp->mp_seg[T] .memjvir = 0; 

17429 rmp->mp_seg[T] ,mem_len = text_clicks; 

17430 } 

17431 rmp->mp_seg[D] ,mem_phys = new_base + text_clicks; 

17432 rmp->mp_seg[D] .mem vir = 0; 

17433 rmp->mp_seg[D] ,mem_len = data_clicks; 

17434 rmp->mp_seg[S] ,mem_phys = rmp->mp_seg[D] ,mem_phys + data_clicks + gap_clicks; 

17435 rmp->mp_seg[S] ,mem_vir = rmp->mp_seg[D] .mem_vir + data_clicks + gap_clicks; 

17436 rmp->mp_seg[S] ,mem_len= stack_clicks; 

17437 

17438 

17439 sys_newmap(who, rmp->mp_seg); /* informar nuevo mapa al kemel */ 
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17440 

17441 /* Poner en cero bss, espacio y segmento de pila. */ 

17442 bytes = (phys_bytes) (data_clicks + gap_clicks + stack_clicks) « CLICK_SHIFT; 

17443 base = (phys bytes) rmp->mp_seg[D] ,mem_phys « CLICKSHIFT; 

17444 bss_offset = (data_bytes » CLICK SHIFT) « CLICK SHIFT; 

17445 base += bss_offset; 

17446 bytes -= bss_offset; 

17447 

17448 while (bytes > 0) { 

17449 count = MIN(bytes, (phys_bytes) sizeof(zero)); 

17450 if (sys copy (MMPROCNR, D, (phys bytes) zero, 

17451 ABS, 0, base, count) != OK) { 

17452 panic("new_mem can’t zero", NO_NUM); 

17453 } 

17454 base += count; 

17455 bytes -= count; 

17456 } 

17457 

17458 retum(OK); 

17459 } 

17462 /*======= == ======== = ======= = ============= ==== ====== 

17463 * patch_ptr * 

17464 *============ = === = = = == = ==== = == ==== = = = === = == = ==== = == = == = = = = 

17465 PRIVATE void patch_ptr(stack, base) 

17466 char stack[ARG_MAX]; /* apunto a imagen de pila dentro de MM */ 

17467 vir_bytes base; /* dir. virtual de base pila dentro de usuario */ 

17468 { 

17469 /* Al ejecutar una llamada exec(name, argv, envp), el usuario 

17470 * crea una imagen de pila con apuntadores arg y env relativos al principio de la 

17471 * pila. Ahora éstos deben reubicarse, pues la pila no está colocada en la dirección 

17472 * 0 en el espacio de direcciones del usuario. 

17473 */ 

17474 

17475 char **ap, flag; 

17476 vir_bytesv; 

17477 

17478 flag = 0; /* cuenta núm. de apuntadores-0 vistos */ 

17479 ap = (char **) stack; /* apunta inicialmente a ’nargs' */ 

17480 ap++; /* ahora apunta a argv[0] */ 

17481 while (flag < 2) { 

17482 if (ap >= (char **) &stack[ARG_MAX]) retum; /* lástima */ 

17483 if(*ap 1=NIL_PTR) { 

17484 v = (vir_bytes) *ap; /* v es apuntador relativo */ 

17485 v+=base; /* reubicarlo */ 

17486 *ap = (char *) v; /* regresarlo */ 

17487 } else { 

17488 flag++; 

17489 } 

17490 ap++; 

17491 } 

17492 } 

17495 /*==== ==== == === ==^ = === = = === = === = ===== 

17496 * load_seg * 

17497 * = = = = = ===== = = = = == = = = === === = = = = == = = = = = == = = = === = = = = = == = = = = == == 

17498 PRIVATE void load_seg(fd, seg, seg bytes) 

17499 int fd; /* descriptor de arch del cual leer */ 
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17500 intseg; 7*ToD*/ 

17501 vir_bytes seg_bytes; /* qué tan grande es el segmento *1 

17502 { 

17503 /* Leer texto o datos del arch. ejecutable y copiar en nueva imagen de núcleo. 

17504* Este procedo es algo complicado. La forma lógica de cargar un segmento 

17505 * sería leerlo bloque por bloque y copiar uno a la vez en el espacio de usuario. 

17506 * Esto es muy lento, así que hacemos algo sucio aquí: enviar el espacio de usuario 

17507 * Y la dirección virtual al FS en los 10 bits superiores del descriptor de archivo, 

17508 * Y le pasamos la dir. virtual del usuario en vez de una dirección MM. 

17509 * El FS extrae estos parámetros cuando recibe una llamada de lectura del MM, 

17510* que es el único proceso que tiene permitido usar este truco. A continuación, 

17511 * el FS copia todo el segmento directamente en espacio de usuario, 

17512 * pasando totalmente por alto el MM. 

17513 */ 

17514 

17515 int new_fd, bytes; 

17516 char *ubuf_ptr; 

17517 

17518 new fd = (who « 8) | (seg « 6) | fd; 

17519 ubuf_ptr = (char *) ((vir_bytes)mp->mp_seg[seg] ,mem_vir « CLICK_SHIFT); 

17520 while (seg_bytes 1= 0) { 

17521 bytes = (INT MAX 1 8LOCK SIZE) * BLOCKSIZE; 

17522 if (seg_bytes < bytes) 

17523 bytes = (int)seg_bytes; 

17524 if (read(new_fd, ubuf_ptr, bytes) != bytes) 

17525 break; /* error */ 

17526 ubuf_ptr+= bytes; 

17527 seg_bytes -= bytes; 

17528 } 

17529 } 

17532 1 *= = = = = = = = = = = = = = = === === === = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 

17533* fmdshare * 

17534 *=======================-===================================== 

17535 PUBLIC struct mproc *fmd_share(mp_ign, ino, dev, ctime) 

17536 struct mproc *mp_ign; /* proceso que no debe mirarse */ 

17537 ino_t ino; /* paráms. que identif. de forma única un arch. *1 

17538 devjdev; 

17539 time_t ctime; 

17540 { 

17541 /* Buscar un proceso que sea el archivo <ino, dev, ctime> en ejecución. 

17542 * No "encontrar" accidentalmente" mp_ign, porque es el proceso a nombre del cual 

17543 * se hace esta llamada. 

17544 *1 

17545 struct mproc *sh_mp; 

17546 

17547 for (sh mp = &mproc[INIT_PROC_NR]; sh mp < &mproc[NR_PROCS]; sh_mp++) { 

17548 if ((sh mp->mp flags & (IN USE | HANGING | SEPARATE)) 

17549 != (INUSE | SEPARATE)) continué; 

17550 if (sh_mp = mp_ign) continué; 

17551 if (sh_mp->mp_ino ! = ino) continué; 

17552 if (sh_mp->mp_dev != dev) continué; 

17553 if (sh_mp->mp_ctime 1= ctime) continuej 

17554 retum sh_mp; 

17555 } 

17556 retum(NULL); 

17557 } 
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17600 /* El modelo MINIX de reparto de memoria reserva una cantidad fija para los 

17601 * segmentos combinados de texto, datos y pila. La cantidad empleada para un proc. 

17602 *.hijo creado por FORK es la misma que tenia el padre. Si el hijo hace EXEC 

17603 * después, el nuevo tamaño se toma de la cabecera del archivo EXECutado. 

17604 * 

17605 * La organizo en memoria consiste en el segm. de texto, seguido del de datos, 

17606 * seguido de un espacio (memoria no usada), seguido por el segm. de pila. 

17607 * El segm. de datos crece hacia arriba y el de pila hacia abajo, asi que ambos 

17608 * pueden tomar memoria del espacio. Si chocan, el proceso debe morir. 

17609 * Los procedo de este arch. se ocupan del crecimiento de estos segmentos. 

17610 * 

17611 * Los puntos de entrada a este archivo son: 

17612* do brk: llamadas BRK/SBRK p/crecer o encoger segm. de datos 

17613* adjust: ver si se permite un ajuste de segmento propuesto 

17614 * size_ok: ver si los tamaños de los segmentos son factibles 

17615 */ 

17616 

17617 #include "mm.h" 

17618 #include <signal.h> 

17619 #include "mproc.h" 

17620 #include "param.h" 

17621 

17622 #define DATA CHANGED 1 /* valor bandera si cambió tamo segm. datos 


17623 #define STACK CHANGED 2 /* valor bandera si cambió tamaño de pila */ 

17624 

17625 /*======= = = = ===================== = = ==== === = =* 

17626* do_brk * 

17627 *=== = = = = = == = = = = = = = ======= = = = = == = = = = = == =^== = = = = === = = = = = = = ==== = = = == ==*/ 

17628 PUBLIC int do_brk() 

17629 { 

17630 /* Realizar la llamada al sistema brk(addr). 

17631 * 

17632 * La llamada se complica por el hecho de que en algunas máquinas (p.ej. 8088) 

17633 * el apuntador a la pila puede crecer más allá de la base del segmento 

17634 * de pila sin que nadie se dé cuenta. 

17635 * El parámetro, ’addr', es la nueva dirección virtual en espacio D. 

17636 */ 

17637 

17638 register struct mproc *rmp; 

17639 int r; 

17640 vir_bytes v, new_sp; 

17641 vir_clicks new_clicks; 

17642 

17643 rmp = mp; 

17644 v = (vir_bytes) addr; 

17645 new_clicks = (vir clicks) ( ((long) v + CLICK SIZE -1) » CLICK SHIFT); 

17646 if (new_clicks < rmp->mp_seg[D] ,mem_vir) { 

17647 res_ptr = (char *) -1; 

17648 retum(ENOMEM); 

17649 } 

17650 new clicks -= rmp->mp_seg[D] .memvir; 

17651 sys_getsp(who, &new_sp); /* pedir a kemel valor sp actual */ 

17652 r = adjust(rmp, new_clicks, new_sp); 

17653 res_ptr = (r == OK ? addr : (char *) -1); 

17654 retum(r); /* devolver nva. dirección o -1 */ 
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17658 /*=========== = = — == — =========== 

17659 * adjust 

17660 *==== == ==== =^ ========= — ===== ==== ===== 

17661 PUBLIC int adjust(rmp, data_clicks, sp) 

17662 register struct mproc *rmp; /* ¿de quién se ajusta la memoria? *1 

17663 vir clicks data clicks; /* ¿cuánto debe crecer segm. datos? *1 

17664 vii=bytes sp; -/* nuevo valor de apunto a pila (sp) *1 

17665 { 

17666 /* Ver si los segm. de datos y pila pueden coexistir, ajustándolos si es necesario. 

17667 * Nunca se asigna ni libera memoria; se agrega o quita del espacio entre los segms. 

17668 * de datos y de pila. Si el tamaño del espacio se vuelve negativo, 

17669 * el ajuste de datos o pila falla y se devuelve ENOMEM. 

17670 *1 

17671 

17672 register struct mem_map *mem_sp, *mem_dp; 

17673 vir_clicks sp_click, gap_base, lower, old_clicks; 

17674 int changed, r, ft; 

17675 long base_of_stack, delta; 1 * longs evitan ciertos problemas *1 

17676 

17677 mem dp = &rmp->mp_seg[D]; /* apunto a mapa de segm. de datos */ 

17678 mem sp = &rmp->mp_seg[S]; /* apunto a mapa de segm. de pila *1 

17679 changed = 0; 1 * encend. si cambió uno de los seg. *1 

17680 

17681 if (mem_sp->mem_len = 0) retum(OK); 1 * no molestar a init *1 

17682 

17683 /* Ver si tamaño pila se hizo negat. (sp demasiado cerca de OxFFFF...) *1 

17684 base of stack = (long) mem sp->mem vir + (long) mem sp->mem_len; 

17685 sp_click = sp » CLICK_SHIFT; 1 * clic que contiene sp */ 

17686 if (sp_click >= base_of_stack) retum(ENOMEM); /* sp demasiado alto */ 

17687 

17688 1 * Calcular tamaño de espacio entre segmentos de datos y de pila. */ 

17689 delta = (long) mem_sp->mem_vir .(long) sp_click; 

17690 lower = (delta> 0 ? sp_click : mem_sp->mem_vir); 

17691 

17692 /* Agregar margen segurid. p/futuro crecim. pila. Imposible hacer bien. */ 

17693 #defme SAFETV BVTES (384 * sizeof(char *)) 

17694 #defme SAFETV=CLICKS ((SAFETV BVTES + CLICKSIZE -1)1 CLICKSIZE) 

17695 gap base = mem_dp->mem_vir + data clicks + SAFETV CLICKS; 

17696 if (lower < gap_base) retum(ENOMEM); 1* datos y pila chocaron *1 

17697 

17698 /* Actualiz. long. datos (pero no su origen) a nombre de la llamada brk(). */ 

17699 old_clicks = mem_dp->mem_len; 

17700 if (data_clicks 1= mem_dp->mem_len) { 

17701 mem_dp->mem_len = data_clicks; 

17702 changed 1 = DATACHANGED; 

17703 } 

17704 

17705 /* Actualiz. longitud y origen de pila por cambio en apuntador a pila. */ 

17706 if(delta>0){ 

17707 mem_sp->mem_vir -= delta; 

17708 mem_sp->mem_phys -= delta; 

17709 mem_sp->mem_len += delta; 

17710 changed 1= STACKCHANGED; 

17711 } 

17712 

17713 1* ¿Caben en espacio de dir. nuevos tamaños de segm. de datos y de pila? *1 

17714 ft = (rmp->mp_flags & SEPARATE); 
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17715 r = size_ok(ñ, rmp->mp_seg[T] ,mem_len, rmp->mp_seg[D] ,mem_len, 

17716 rmp->mp_seg[S] .mem len, rmp->mp_seg[D] .memvir, rmp->mp_seg[S] .memvir); 

17717 if(r = OK) { 

17718 if (changed) sys_newmap((int)(rmp -mproc), rmp->mp_seg); 

17719 retum(OK); 

17720 } 

17721 

17722 /* Nvos tamaños no caben o req demasiados regs pág/segm. Restaurar.*/ 

17723 if (changed & DATA_CHANGED) mem_dp->mem_len = old_clicks; 

17724 if (changed & STACK CHANGED) { 

17725 mem_sp->mem_vir += delta; 

17726 mem_sp->mem_phys += delta; 

17727 mem_sp->mem_len -= delta; 

17728 } 

17729 retum(ENOMEM); 

17730 } 

17733 /*===== == = = ====== == ===== = === = = ==== = == =* 

17734* size_ok * 

17735 * ==== == ====== == ====== = ========== */ 

17736 PUBLIC int size_ok(file_type, te, de, se, dvir, s_vir) 

17737 int file_type; /* SEPARATE o 0 */ 

17738 vir_clicks tC; /* tamaño texto en clics */ 

17739 vir_clicks de; /* tamaño datos en clics */ 

17740 vir_clicks SC; /* tamaño pila en clics */ 

17741 vir_clicks dvir; /* dir. virtual p/inicio seg. datos */ 

17742 vir_clicks s_vir; /* dir. virtual p/inicio seg. pila */ 

17743 { 

17744 /* Ver si tamaños son factibles y hay suficientes registros de segmentación. 

17745 * En una máquina con 8 págs. de 8K, tamaños de texto, datos, pila 

17746 * de (32K, 16K, 16K) caben, pero (33K, 17K, 13K) no, aunque lo primero 

17747 * es mayor (64K) que lo segundo. Aun en el 8088 se necesita esta prueba, 

17748 * pues los datos y pila no pueden exceder 4096 clics. 

17749 */ 

17750 

17751 #if (CHIP == INTEL && WORD SIZE = 2) 

17752 int pt, pd, ps; /* tamaños segmentos en páginas */ 

17753 

17754 pt = ((tc« CLICKSHIFT) + PAGESIZE 1)/PAGE_SIZE; 

17755 pd = ( (de « CLICK SHIFT) + PAGE SIZE 1)/PAGE_SIZE; 

17756 ps = ((sc« CLICK SHIFT) + PAGE SIZE 1)/PAGE_SIZE; 

17757 

17758 if (file_type = SEPARATE) { 

17759 if (pt > MAXPAGES | | pd + ps > MAXPAGES) retum(ENOMEM); 

17760 } el se { 

17761 if (pt + pd + ps > MAX PAGES) retum(ENOMEM); 

17762 } 

17763 #endif 

17764 

17765 if (dvir + de > s_vir) retum(ENOMEM); 

17766 

17767 retum(OK); 

17768 } 






EL CÓDIGO FuENTE DE MINIX Archivo: src/mmJsignal.c 


769 


src/mm/signal.c 


17800 /* Este archivo maneja señales, que son eventos asincronos y en general 

17801 * un asunto desagradable. Se pueden generar con la llamada KILL 

17802 * o por el teclado (SIGINT) o el reloj (SIGALRM). En todos 

17803 * los casos el control finalmente pasa a check_sig() para ver cuáles procesos 

17804 * pueden señalizarse. La señalización en sí la realiza sig_proc(). 

17805 * 

17806 * Los puntos de entrada a este archivo son: 

17807* do_sigaction: realizar llamada al sistema SIGACTION 

17808* do_sigpending: realizar llamada al sistema SIGPENDING 

do sigprocmask: realizar llamada al sistema SIGPROCMASK 
dO-Sigretum: realizar llamada al sistema SIGRETURN 

do_sigsuspend: realizar llamada al sistema SIGSUSPEND 

do_kill: realizar llamada al sistema KILL 

do_ksig: aceptar señal que se origina en el kemel (p.ej. SIGINT) 

do_alarm: realizar llamada al sist. ALARM invocando set_alarm() 

set_alarm: decir a la tarea del reloj que inicie o pare un temporiz. 
do_pause: realizar la llamada al sistema PAUSE 

do_reboot: matar todos los procesos y rearrancar el sistema 
sig_proc: interrumpir o terminar un proceso señalizado 

check_sig: verif. cuáles procesos señalizar con sig_proc() 


17809* 

17810* 

17811* 

17812* 

17813* 

17814* 

17815* 

17816* 

17817* 

17818* 

17819* 

17820 

17821 

17822 

17823 

17824 

17825 

17826 

17827 

17828 

17829 

17830 

17831 

17832 

17833 

17834 

17835 

17836 

17837 

void check_pending, (void) 

17838 

void dump_core, (struct mproc *rmp) 

17839 

void unpause, (int pro) 

17840 

17841 


#include "mm.h" 

#include <sys/stat.h> 

#include <minix/callnr.h> 
#include <minix/com.h> 

#include <signal.h> 
#include <sys/sigcontext.h> 
#include <string.h> 
#include "mproc.h" 

#include "param.h" 


#define CORE MODE 
#define DUMPED 
#define DUMP SIZE 


0777 /* modo a usar en arch. de imagen núc. */ 

0200 /* bit encend. cuando se vacía núcleo */ 

((INT MAX / BLOCK SIZE) * BLOCK SrZE) 


/* tamaño buffer p/vaciado núcleo */ 


FORWARD _PROTOTYPE( 

); 

FORWARD _PROTOTYPE( 

); 

FORWARD _PROTOTYPE( 


PUBLIC int do sigactionQ 


17842/* 

17843* 

17844 

17845 

17846 

17847 in 

17848 struct sigaction svec; 

17849 struct sigaction *SVp; 

17850 


17851 if (sig_nr = SIGKILL) retum(OK); 

17852 if (sig_nr < 1 11 sig_nr > _NSIG) retum (EINVAL); 

17853 svp = &mp->mp_sigact[sig_nr]; 

17854 if ((struct sigaction *) sig_osa != (stmct sigaction *) NULL) { 
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17855 

17856 

17857 

17858 

17859 

17860 

17861 

17862 

17863 

17864 

17865 

17866 

17867 

17868 

17869 

17870 

17871 

17872 

17873 

17874 

17875 

17876 

17877 

17878 

17879 

17880 

17881 

17882 

17883 

17884 

17886 / 

17887 < 

17888 * 

17889 

17890 

17891 

17892 

17893 

17895 í 

17896 4 

17897 * 

17898 

17899 

17900 

17901 * 

17902 4 

17903 ! 

17904 

17905 4 

17906 s 

17907 

17908 

17909 

17910 

17911 

17912 

17913 

17914 
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r = sys_copy(MM_PROC_NR,D, (phys bytes) svp, 

who, D, (phys_bytes) sig_osa, (phys_bytes) sizeof(svec)); 
if (r 1= OK) retum(r); 


if ((struct sigaction *) sig_nsa = (struct sigaction *) NULL) retum(OK)j 

/* Leer la estructura sigaction. */ 
r = sys_copy(who, D, (phys_bytes) sig_nsa, 

MMPROCNR, D, (phys bytes) &svec, (phys bytes) sizeof(svec)); 
if (r != OK) retum(r); 

if (svec.sa handler = SIGIGN) { 

sigaddset(&mp->mp_ignore, sig_nr); 
sigdelset(&mp->mp_sigpending, sig_nr); 
sigdelset(&mp->mp_catch, sig_nr); 

} else { 

sigdelset(&mp->mp_ignore, sig_nr); 
if (svec.sa_handler = SIGDFL) 

sigdelset(&mp->mp_catch, sig_nr); 

else 

sigaddset(&mp->mp_catch, sig_nr) j 

} 

mp->mp_sigact[sig_nr] ,sa_handler= svec.sa_handler; 
sigdelset(&svec.sa_mask, SIGKILL); 
mp->mp_sigact[sig_nr] ,sa_mask = svec.sa_mask; 
mp->mp_sigact[sig_nr] ,sa_flags = svec.sa_flags; 
mp->mp_sigretum = (vir_bytes) sig_ret; 
retum(OK); 


* do_sigpending 

PUBLIC int do_sigpending() 

{ 

ret_mask = (long) mp->mp_sigpending; 
retum OK; 


do sigprocmask 

PUBLIC int do_sigprocmask() 

{ 

/* La interfaz de biblioteca pasa la máscara real en sigmask_set, 

* no un apuntador a ella, para ahorrar un sys_copy. Así mismo, 

* la máscara vieja se pone en el mensaje de retomo que la interfaz 

* copia (si se le pide) en la dirección especificada por el usuario. 

* La interfaz de biblioteca debe establecer SIG INQUIRE si el argumento 

’acf es NULL. 


ret_mask = (long) mp->mp_sigmask; 

switch (sig_how) { 

case SIG BLOCK: 
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17915 sigdelset((sigset_t *)&sig_set, SIGKILL); 

17916 for (i = 1; i < _NSIG; i++) { 

17917 if (sigismember((sigset_t *)&sig_set, i)) 

17918 sigaddset(&mp->mp_sigmask, i); 

17919 } 

17920 break; 

17921 . 

17922 case SIGJJNBLOCK: 

17923 for (i = 1; i < _NSIG; i++) { 

17924 if (sigismember((sigset_t *)&sig_set, i)) 

17925 sigdelset(&mp->mp_sigmask, i); 

17926 } 

17927 check_pending(); 

17928 break; 

17929 

17930 case SIG SETMASK: 

17931 sigdelset((sigset_t *)&sig_set, SIGKILL); 

17932 mp->mp_sigmask = (sigset_t)sig_set; 

17933 check_pending(); 

17934 break; 

17935 

17936 case SIG_INQUIRE: 

17937 break; 

17938 

17939 default: 

17940 retum(EINVAL); 

17941 break; 

17942 } 

17943 retumOK; 

17944 } 

17946 /*================================= = ======= 

17947 * do_sigsuspend 

17948 *======================== —== ============== 

17949 PUBLIC int do_sigsuspend() 

17950 { 

17951 mp->mp_sigmask2 = mp->mp_sigmask; /* guardar la máscara vieja */ 

17952 mp->mp_sigmask = (sigset t) sig_set; 

17953 sigdelset(&mp->mp_sigmask, SIGKILL); 

17954 mp->mp_flags 1= SIGSUSPENDED; 

17955 dont_reply = TRUE; 

17956 check_pending(); 

17957 retumOK; 

17958 } 

17961 /*=================== == ============== = ===== = 

17962* do_sigretum 

17963 *========================= —- - === =============== 

17964 PUBLIC int do_sigretum() 

17965 { 

17966 /* Un manejador de señales de usuario acabó. Restaurar contexto 
17967* Y ver si no hay señales no bloqueadas pendientes. 

17968 */ 

17969 

17970 int r; 

17971 

17972 mp->mp_sigmask = (sigset_t) sig_set; 

17973 sigdelset(&mp->mp_sigmask, SIGKILL); 

17974 
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17975 r = sys_sigretum(who, (vir_bytes) sig_context, sig_flags); 

17976 check_pending(); 

17977 retum(r); 

17978 } 

17980 /*===== === === === = === == 

17981 * do_kill 

17982 * = = == ========== = = = === == ==== = = = = == = 

17983 PUBLIC int do_kill() 

17984 { 

17985 /* Realizar llamada al sistema kill(pid, signo). */ 

17986 

17987 retum check_sig(pid, sig_nr); 

17988 } . 


17991 r 

17992 

17993 * 

17994 

17995 

17996 

17997 

17998 

17999 

18000 
18001 
18002 

18003 

18004 

18005 

18006 

18007 

18008 
18009 


18012 

18013 

18014 

18015 

18016 

18017 

18018 

18019 

18020 
18021 
18022 

18023 

18024 

18025 

18026 

18027 

18028 

18029 

18030 

18031 

18032 

18033 

18034 


do_ksig 


PUBLIC int do_ksig() 

{ 

/* Ciertas señales, como violaciones de segmentación y DEL se originan 

* en el kemel. Cuando el kemel las detecta, enciende bits en un mapa de bits. 

* Apenas el MM está esperando nuevo trabajo, el kemel le envía un mensaje con la 

* ranura de proceso y mapa de bits. El mensaje llega aquí. El FS también usa 

* este mecanismo para indicar escritura en conductos rotos (SIGPIPE). 


register struct mproc *rmp; 
int i, proc_nr; 
pid_t proc_id, id; 
sigset_t sig_map; 

/* Sólo el kemel puede hacer esta llamada. */ 

if (who != HARDWARE) retum(EPERM); 

dont_reply = TRUE; /* no responder al kemel */ 

procnr = mmin.SIGPROC; 

rmp = &mproc[proc_nr]; 

if ( (rmp->mp_flags & IN USE) = 0 11 (rmp->mp_flags & HANGING)) retum(OK); 

proc_id = rmp->mp_pid; 

sig map = (sigset t) mm_in.SIG_MAP; 

mp = &mproc[0]; /* fingir señales kemel son del MM */ 

mp->mp_procgrp = rmp->mp_procgrp; /* obt. gpo. de procesos correcto */ 

/* Verificar cada bit p/ver si debe enviarse una señal. A diferencia 

* de kill(), el kemel puede reunir varias señales no relacionadas para un 

* proceso y pasarlas al MM de un golpe. De ahí la iteración sobre 

* el mapa de bits. Para SIGINT y SIGQUIT, usar proc id 0 para indicar 

* una difusión al grupo de procesos del destinatario. Para SIGKILL, 

* usar proc_id -1 para indicar una difusión a todo el sistema. 

for (i = 1; i <= _NSIG; i++) { 

if (!Sigismember(&sig_map, i)) continué; 
switch (i) { 
case SIGINT: 
case SIGQUIT: 

id = 0; break; /* difundir a grupo de procesos */ 

case SIGKILL: 

id = -1; break; /* difundir a todos excepto INIT */ 
case SIGALRM: 


*/ 


*/ 
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18035 /* No hacer caso de SIGALRM cuando el proceso objetivo 

18036 * no solicitó una alarma. Esto sólo aplica a una señal 

18037 * generada por el kemel. 

18038 */ 

18039 if ((rmp->mp_flags & ALARMON) = 0) continué; 

18040 rmp->mp_flags &= -ALARM ON; 

18041 /* caer a la siguiente rutina */ 

18042 default: 

18043 id = proc_id; 

18044 break; 

18045 } 

18046 check_sig(id, i); 

18047 sys_endsig(proc_nr); /* decir al kemel que acabó */ 

18048 } 

18049 retum(OK); 

18050 } 

18053 /*================== = ================= = ======= === 

18054 * do_alarm 

18055 *============================== = ===================== = 

18056 PUBLIC int do_alarm() 

18057 { 

18058 /* Realizar la llamada al sistema alarm(seconds). */ 

18059 

18060 retum(set_alarm(who, seconds)); 

18061 } 

18064 /♦==== ==== == === == ====== = === = ===== 

18065 * set_alarm 

18066 *========================- ====== == ===================== === 

18067 PUBLIC int set_alarm(proc_nr, sec) 

18068 intproc_nr; /* proceso que quiere la alarma */ 

18069 int sec; /* retardo (seg) antes de la señal */ 

18070 { 

18071 /* Do_alarm usa esta rutina p/fijar temporiz. de alarma. También sirve p/apagar 

18072 * el temporiz. cuando un proceso sale con el temporiz. aún encendido. 

18073 */ 

18074 

18075 message m_sig; 

18076 int remaining; 

18077 

18078 if (sec 1=0) 

18079 mprocfproc nr] .mp flags 1= ALARM ON; 

18080 else 

18081 mproc[proc_nrl.mp_flags &= -ALARM_ON; 

18082 

18083 /* Decir a tarea de reloj envíe mensaje de señal cuando llegue el momento. 

18084 * 

18085 * Retardos largos causan muchos problemas. Primero, la llamada alarm 

18086 * recibe una cuenta de segundos unsigned y la biblioteca la mutó a un int. 

18087 * Eso quizá funcione, pero al regresar la bibl. convertirá unsigned "negativos" 

18088 * en errores. Supuestamente nadie verifica estos errores, y se fuerza 

18089 * a la llamada a seguir. Segundo, si unsigned y long tienen el mismo 

18090 * tamaño, la conversión de segundos a tics fácilmente puede desbordarse. 

18091 * Por último, el kemel tiene desbordam. similares al sumar tics. 

18092 * 

18093 * Corregir esto requiere muchas mutaciones feas para caber en los tipos 

18094 * de interfaz equivocados y evitar trampas de desbordam. DELTA_TICKS 


*/ 


*/ 
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18095 * tiene el tipo correcto (clock_t) aunque se declara como long. 

18096 * ¿Cómo pueden declararse debidamente variables como ésta sin una explosión 

18097 * combinatoria de tipos de mensajes? 

18098 */ 

18099 m sig.m type = SET ALARM; 

18100 m sig.CLOCK PROC NR = proc_nr; 

18101 m_síg.DELTA_TICKS = (clock_t) (HZ * (unsigned long) (unsigned) sec); 

18102 if ( (unsigned long) msig.DELTATICKS / HZ != (unsigned) sec) 

18103 m sig.DELTA TICKS = LONGMAX; /* eternidad (real. CLOCK T MAX) */ 

18104 if (sendrec(CLOCK, &m_sig) != OK) panic("alarm er", NO_NUM); 

18105 remaining = (int) m_sig.SECONDS_LEFT; 

18106 if (remaining != m_sig.SECONDS_LEFT | | remaining < 0) 

18107 remaining = INT_MAX; /* el valor real no es representable */ 

18108 retum(remaining); 

18109 } 

18112 /*====== = = == === = ====== = = = == === ==== = ==== == ==== == === = == = == 

18113 * do_pause * 

18114 * = = == = = === = = = === = = = = === = = = = == ==== = = = = = == = = = = = === == == = === 

18115 PUBLIC int do_pause() 

18116 { 

18117/* Realizar la llamada al sistema pause(). */ 

18118 

18119 mp->mp_flags 1= PAUSED; 

18120 dont_reply = TRUEj 

18121 retum(OK) j 

18122 } 


do_reboot 


PUBLIC int do_reboot() 

{ 

register struct mproc *rmp = mp; 
char monitor_code[64]; 

if (rmp->mp_effiiid != SUPER USER) retum EPERM; 

switch (reboot_flag) { 
case RBT HALT: 
case RBT REBOOT: 
case RBTPANIC: 
case RBT RESET: 

case RBTMONITOR: 

if (reboot_size > sizeof(monitor_code)) retum EINVAL; 
memset(monitor_code, 0, sizeof(monitor_code)); 
if (sys_copy(who, D, (phys_bytes) reboot_code, 

MMPROCNR, D, (phys bytes) monitor code, 
(phys_bytes) reboot_size) != OK) retum EFAULT; 
if (monitor_code[sizeof(monitor_code)-l] != 0) retum EINVAL; 

default: 

retum EINVAL; 

} 

/* Matar todos los procesos excepto init. */ 
check_sig(-l. 


18125, 

18126 
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18128 
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18155 

18156 tell_fs(EXIT, INIT_PROC_NR, 0, 0); /* asear init */ 

18157 

18158 tell_fs(SYNC,0,0,0); 

18159 

18160 sys_abort(reboot_flag, monitor_code); 

18161 /* NOTREACHED */ 

18162 } 

18165 /*===== === ====== == ==== == = ====== = === * 

18166 * sig_proc * 

18167 *===== = ====== = ======== = ======= == = = === = = == = = = = == == == = = = == = ======*/ 

18168 PUBLIC void sig_proc(rmp, signo) 

18169register struct mproc *rmp; /* apunto al proceso por señalizar */ 

18170int signo; /* señal a enviar al proceso (1 a _NSIG) */ 

18171 { 

18172 1* Enviar señal a un proceso. Ver si la señal debe atraparse, ignorarse 

18173 * o bloquearse. Si debe atraparse, coordinar con KERNEL para meter 

18174 * una struct sigcontext y una sigframe en la pila de quien atrapará. 

18175 * Además, KERNEL restablecerá el contador de programa y el apuntador 

18176 * de pila, para que la siguiente vez que el proceso se ejecute, ejecute 

18177 * el manejador de señales. Cuando éste regrese, se invocará 

18178 * sigretum(2). Luego KERNEL restaurará el contexto de la señal 

18179 * de la estructura sigcontext. 

18180 * 

18181 *Sino hay suficiente espacio en pila, matar el proceso. 

18182 */ 

18183 

18184 vir_bytes new_sp; 

18185 intslot; 

18186 int sigflags; 

18187 struct sigmsg sm; 

18188 

18189 slot = (int) (rmp -mproc); 

18190 if (! (rmp->mp_flags & INUSE)) { 

18191 printf("MM: signal %d sent to dead process %d\n", signo, slot); 

18192 panic("", NO_NUM); 

18193 } 

18194 if (rmp->mp_flags & HANGING) { 

18195 printf("MM: signal %d sent to HANGING process %d\n", signo, slot); 

18196 panic("", NO_NUM); 

18197 } 

18198 if (rmp->mp_flags & TRACED && signo 1= SIGKILL) { 

18199 /* Un proceso perseguido tiene manejo especial. */ 

18200 unpause(slot); 

18201 stop_proc(rmp, signo); /* una señal lo hace que pare */ 

18202 retum; 

18203 } 

18204 /* Algunas señales se ignoran por omisión. */ 

18205 if (sigismember(&rmp->mp_ignore, signo)) retum; 

18206 

18207 if (sigismember(&rmp.>mp_sigmask, signo)) { 

18208 /* La señal debe bloquearse. */ 

18209 sigaddset(&rmp->mp_sigpending, signo); 

18210 retum; 

18211 } 

18212 sigflags = rmp->mp_sigact[signo] ,sa_flags; 

18213 if (sigismember(&rmp->mp_catch, signo)) { 

18214 if (rmp->mp_flags & SIGSUSPENDED) 
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18215 sm.sm_mask = rmp->mp_sigmask2; 

18216 else 

18217 sm.smmask = rmp->mp_sigmask; 

18218 sm.sm_signo = signo; 

18219 sm.sm_sighandler = (vir_bytes) rmp->mp_sigact[signo] ,sa_handler; 

18220 sm.sm_sigretum = rmp->mp_sigretum; 

18221 sys_getsp(slot, &new_sp); 

18222 sm.sm_stkptr = new_sp; 

18223 

18224 /* Hacer espacio para las struct sigcontext y sigffame. */ 

18225 new_sp - = sizeof(struct sigcontext) 

18226 + 3 * sizeof(char *) + 2 * sizeof(int); 

18227 

18228 if (adjust(rmp, rmp->mp_seg[D] ,mem_len, new_sp) != OK) 

18229 goto doterminate; 

18230 

18231 rmp->mp_sigmask 1= rmp->mp_sigact[signo] ,sa_mask; 

18232 if (sigflags & SANODEFER) 

18233 sigdelset(&rmp->mp_sigmask, signo); 

18234 else 

18235 sigaddset(&rmp->mp_sigmask, signo); 

18236 

18237 if (sigflags & SA RESETHAND) { 

18238 sigdelset(&rmp->mp_catch, signo); 

18239 rmp->mp_sigact[signo] ,sa_handler = SIG_DFL; 

18240 } 

18241 

18242 sys_sendsig(slot, &sm); 

18243 sigdelset(&rmp->mp_sigpending, signo); 

18244 /* Si el proceso está suspendido por PAUSE, WAIT, SIGSUSPEND, tty, 

18245 * conducto, etc., liberarlo. 

18246 *1 

18247 unpause(slot); 

18248 retum; 

18249 } 

18250 doterminate: 

18251 /* La señal no debe o no puede atraparse. Terminar el proceso. */ 

18252 rmp->mp_sigstatus = (char) signo; 

18253 if (sigismember(&core_sset, signo)) { 

18254 /* Conmutar al entorno de FS del usuario y vaciar núcleo. */ 

18255 tell_fs(CHDIR, slot, FALSE, 0); 

18256 dump_core(rmp); 

18257 } 

18258 mm_exit(rmp, 0); /* terminar el proceso */ 

18259 } 


18262 /*===== === ====== === === == = ====== = === * 

18263 * check_sig * 

18264 *== = ========================== ==== === = = = ====== == == = = = = == === = = = */ 

18265 PUBLIC int check_sig(proc_id, signo) 

18266 pid_t proc_id; /* pid de proc a señalizar, o 0 o -1 o -pgrp */ 

18267 int signo; /* señal a enviar al proc (0 a _NSIG) */ 

18268 { 

18269 /* Ver si es posible enviar una señal. Quizá haya que enviar la señal 

18270 * a un grupo de procs. Esta rutina es invocada por la llamada al sistema KILL, 

18271 * Y también cuando el kemel atrapa DEL u otra señal. 

18272 */ 

18273 

18274 register struct mproc *rmp; 
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18275 int count; /* contar núm. de señales enviadas *1 

18276 int error_code; 

18277 

18278 if (signo < 0 | | signo> _NSIG) retum(EINVAL); 

18279 

18280 /* Devolver EESTVAL en intentos por enviar SIGKILL sólo a INIT. *1 

18281 if (proC id == INIT PID && signo = SIGKILL) retum(EINVAL); 

18282 

18283 1 * Buscar en la tabla de procesos aquellos a los que se señalizará. (Ver forkexit.c 

18284 * en lo que toca a magia de pid.) 

18285 *1 

18286 count = 0; 

18287 errorcode = ESRCH; 

18288 for (rmp = &mproc[INIT_PROC_NRlj rmp < &mproc[NR_PROCS]; rmp++) { 

18289 if ( (rmp->mp_flags & IN_USE) = 0) continué; 

18290 if (rmp->mp_flags & HANGING && signo != 0) continué; 

18291 

18292 1 * Verificar selección. *1 

18293 if (proc_id > 0 && proc_id 1= rmp->mp_pid) continué; 

18294 if (proc_id = 0 && mp->mp_procgrp 1= rmp->mp_procgrp) continué; 

18295 if (proc_id = -1 && rmp->mp_pid = INIT_PID) continué; 

18296 if (proc_id < -1 && rmp->mp_procgrp 1= -proc_id) continué; 

18297 

18298 1* Verificar permiso. *1 

18299 if (mp->mp_effiiid 1 = SUPERUSER 

18300 && mp->mp_realuid != rmp->mp_realuid 

18301 && mp->mp_effiiid != rmp->mp_realuid 

18302 && mp->mp_realuid != rmp->mp_effuid 

18303 && mp->mp_effiiid != rmp->mp_effiiid) { 

18304 errorcode = EPERM; 

18305 continué; 

18306 } 

18307 

18308 count++; 

18309 if (signo = 0) continué; 

18310 

18311 1* ’sig_proc' se encarga de procesar la señal, que puede ser atrapada, 

18312 * bloqueada, ignorada o causar la terminación del proceso, 

18313 * quizá con vaciado de núcleo. 

18314 *1 

18315 sig_proc(rmp, signo); 

18316 

18317 if (proc_id > 0) break; 1 * sólo un proceso señalizado *1 

18318 } 

18319 

18320 /* Si el proceso invocador se mató a si mismo, no contestar. */ 

18321 if ((mp->mp_flags & INUSE) = 0 11 (mp->mp_flags & HANGING)) 

18322 dont_reply = TRUE; 

18323 retum(count > 0 ? OK : error_code)j 

18324 } 

18327 ;*===============================================================* 

18328 * check_pending * 

18329 *================================================================*7 

18330 PRIVATE void check_pending() 

18331 { 

18332 1 * Ver si se ha desbloqueado alguna señal pendiente. La primera señal 

18333 * de este tipo que se encuentre se entregará. 

18334 * 
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18335 * Si se encuentran varias señales no enmascaradas pendientes, 

18336 * todas se entregarán en orden. 

18337 * 

18338 * Hay varios lugares en este archivo donde se cambia la máscara 

18339 * de señal. En cada uno, debe invocarse check_pending() 

18340 * para ver si recién se desbloqueó alguna señal. 

18341 */ 

18342 

18343 inti; 

18344 

18345 for (i = 1; i < _NSIG; i++) { 

18346 if (sigismember(&mp->mp_sigpending, i) && 

18347 !sigismember(&mp->mp_sigmask, i)) { 

18348 sigdelset(&mp->mp_sigpending, i); 

18349 sig_proc(mp, i); 

18350 break; 

18351 } 

18352 } 

18353 } 

18356 /♦==—===== = = = —= = == = == == = = = = = = ========= = = = 

18357 * unpause 

18358 *===================================================== 

18359PRIVATE void unpause(pro) 

18360int pro; 1 * cuál número de proceso *1 

18361 { 

18362 1 * Se debe enviar una señal a un proceso. Si el proc está suspendido 

18363 * en una llamada al sist, ésta debe terminarse con EINTR. Posibles 

18364 * llamadas: PAUSE, WAIT, READ Y WRITE, las dos últimas p/conductos y ttys. 

18365 * Primero ver si el proc está susp. por una llamada del MM. Si no, decirlo al FS 

18366 * para que pueda detectar READs y WRITEs de conductos, ttys y demás. 

18367 *1 

18368 

18369 register struct mproc *rmp; 

18370 

18371 rmp = &mproc[pro]; 

18372 

18373 1 * Ver si el proceso está suspendido en una llamada PAUSE. *1 

18374 if ( (rmp->mp_flags & PAUSED) && (rmp->mp_flags & HANGING) = 0) { 

18375 rmp->mp_flags &=-PAUSED; 

18376 reply(pro, EINTR, 0, NILPTR); 

18377 retum; 

18378 } 

18379 

18380 1 * Ver si el proceso está suspendido en una llamada WAIT. *1 

18381 if ( (rmp->mp_flags & WAITING) && (rmp->mp_flags & HANGING) = 0) { 

18382 rmp->mp_flags &=-WAITING; 

18383 reply(pro, EINTR, 0, NIL PTR); 

18384 retum; 

18385 } 

18386 

18387 1 * Ver si el proceso está suspendido en una llamada SIGSUSPEND. *1 

18388 if ((rmp->mp_flags & SIGSUSPENDED) && (rmp->mp_flags & HANGING) = 0) { 

18389 rmp->mp_flags &= -SIGSUSPENDED; 

18390 reply(pro, EINTR, 0, NIL PTR); 

18391 retum; 

18392 } 

18393 

18394 1 * El proceso no está susp. en una 


llamada MM. Pedir al FS que investigue. *1 
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18395 tell_fs(UNPAUSE, pro, 0, 0); 

18396 } 

18399 /*========================================= == ==============* 

18400* dump_core * 

18401 * = = = = = ===== = = = === = = = = === = = = = == ==== = = = = = == = = = = = === == = = = = == === == */ 

18402 PRIVATE void dump core(rmp) 

18403 register struct mproc *rmp; /* de quién se vaciará el núcleo */ 

18404 { 

18405 /* Vaciar el núcleo en el archivo "core" si es posible. */ 

18406 

18407 int fd, fake_fd, nr_written, seg, slot; 

18408 char *buf; 

18409 vir_bytes current_sp; 

18410 phys_bytes left; /* cuidado: 64K podría desbordar vir_bytes *1 

18411 unsigned nr_to_write; 1 * unsigned p/arg a write() pero < INT_MAX *1 

18412 long trace_data, trace_off; 

18413 

18414 slot = (int) (rmp-mproc); 

18415 

18416 1 * ¿Puede escribirse el archivo core? Estamos operando en el entorno FS del 

18417 * usuario, así que no se requieren verificaciones de permisos especiales. 

18418 *1 

18419 if (rmp->mp_realuid != rmp->mp_effuid) return; 

18420 if ( (fd = creat(core_name, CORE MODE)) < 0) return; 

18421 rmp->mp_sigstatus != DUMPED; 

18422 

18423 1 * Asegurarse que el segmento de pila esté actualizado. 

18424 * No queremos que adjust() falle a menos que current_sp sea absurdo, 

18425 * pero podría fallar por verif. de seguridad. Tampoco queremos 

18426 * realmente que el adjust() para enviar una señal falle por verif. de seguridad. 

18427 * Tal vez hacer que SAFETY_BYTES sea un parámetro. 

18428 *1 

18429 sys_getsp(slot, &current_sp); 

18430 adjust(rmp, rmp->mp_seg[D].mem_len, current_sp); 

18431 

18432 /* Escribir mapa de memoria de todos los segmentos p/iniciar archivo coreo *1 

18433 if (write(fd, (char *) rmp->mp_seg, (unsigned) sizeof rmp->mp_seg) 

18434 != (unsigned) sizeof rmp->mp_seg) { 

18435 close(fd); 

18436 return; 

18437 } 

18438 

18439 1 * Escribir toda la entrada de tabla de procs. de kernel p/obtener registros. */ 

18440 trace off = 0; 

18441 while (sys_trace(3, slot, trace_off, &trace_data) = OK) { 

18442 if (write(fd, (char *) &trace_data, (unsigned) sizeof (long)) 

18443 != (unsigned) sizeof (long)) { 

18444 close(fd); 

18445 return; 

18446 } 

18447 trace_off += sizeof (long); 

18448 } 

18449 

18450 1 * Iterar los segmentos y escribirlos. */ 

18451 for (seg = 0; seg < NRSEGSj seg++) { 

18452 buf = (char *) ((vir bytes) rmp->mp_seg[seg].mem_vir « CLICKSHIFT); 

18453 left = (phys bytes) rmp->mp_seg[seg].mem_len « CLICK SHIFT; 

18454 fake_fd = (slot« 8) 1 (seg « 6) I fd; 
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18455 

18456 /* Iterar por un segmento, vaciándolo. */ 

18457 while (left 1= 0) { 

18458 nr_to_write = (unsigned) MIN(left, DUMP_SIZE); 

18459 if ( (nr_written = write(fake_fd, buf, nr_to_write)) < 0) { 

18460 close(fd); 

18461 retum; 

18462 } 

18463 buf += nr_written; 

18464 leñ -= nr_written; 

18465 } 

18466 } 

18467 close(fd); 

18468 } 


src/mm/getset.c 


18500 /* Este archivo maneja las 4 llamadas al sistema que obtienen y fijan uids y gids, 

18501 * asi como getpid(), setsid() y getpgrp(). El código para c/u es tan pequeño 

18502 * que difícilmente se justificaba hacer una función aparte 

18503 * a cada una. 

18504 */ 

18505 

18506 #inc1nde "mm.h" 

18507 #include <minix/callnr.h> 

18508 #include <signal.h> 

18509 #include "mproc.h" 

18510 #include "param.h" 

18511 

18512 /♦================== == ======================= = ======= 

18513 * do_getset 

18514 ♦============================== = ========================== 

18515 PUBLIC int do_getset() 

18516 { 

18517 /* Manejar GETUID, GETGID, GETPID, GETPGRP, SETUID, SETGID, SETSID. Las 4 

18518 * GETs y SETSID devuelven sus resultados primarios en ’r'. GETUID, GETGID 

18519 * Y GETPID también devuelven resultados secundarios (los ID efectivos o el ID 

18520 * del proceso padre) en ’result2', que se devuelve al usuario. 

18521 */ 

18522 

18523 register struct mproc *rmp = mp; 

18524 register int r; 

18525 

18526 switch(mm_call) { 

18527 case GETUID: 

18528 r = rmp->mp_realuid; 

18529 result2 = rmp->mp_effiiid; 

18530 break; 

18531 

18532 case GETGID: 

18533 r = rmp.>mp_realgid; 

18534 result2 = rmp->mp_effgid; 

18535 break; 

18536 

18537 case GETPID: 

18538 r = mproc[who] ,mp_pid; 

18539 result2 = mproc[rmp->mp_parent] ,mp_pid; 
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18540 break; 

18541 

18542 case SETUID: 

18543 if (rmp->mp_realuid != usr_id && rmp->mp effuid 1= SUPER USER) 

18544 retum(EPERM); 

18545 rmp->mp_realuid = usr_id; 

18546 rmp->mp effuid = usr id; 

18547 tell_fs(SETUID, Who, US_id, usr_id); 

18548 r = OK; 

18549 break; 

18550 

18551 case SETGID: 

18552 if (rmp->mp_realgid != grpid && rmp->mp_effiiid != SUPER USER) 

18553 retum(EPERM); 

18554 rmp->mp_realgid = grpid; 

18555 rmp->mp_effgid = grpid; 

18556 tell_fs(SETGID, who, grpid, grpid); 

18557 r = OK; 

18558 break; 

18559 

18560 case SETSID: 

18561 if (rmp->mp_procgrp = rmp->mp_pid) retum(EPERM); 

18562 rmp->mp_procgrp = rmp->mp_pid; 

18563 tell_fs(SETSID, who, 0, 0); 

18564 /*CONTINUAR EN LA SIGUIENTE RUTINA*/ 

18565 

18566 case GETPGRP: 

18567 r = rmp->mp_procgrp; 

18568 break; 

18569 

18570 default: 

18571 r = EINVAL; 

18572 break; 

18573 } 

18574 retum(r); 

18575 } 


src/mm/trace.c 


18600 /* Este archivo se encarga de la parte de la depuración que corresponde al MM, 

18601 * empleando la llamada ptrace. Casi todos los comandos se pasan a la tarea 

18602 * del sistema para que los termine. 

18603 * 

18604 * Los comandos de depuración disponibles son: 

18605 * T STOP detener el proceso 

18606 * T_OK habilitar rastreo de este proceso por el padre 

18607 * T_GETINS devolver valor de espacio de instrucciones 

18608 * T GETDATA devolver valor de espacio de datos 

18609 * T_GETUSER devolver valor de tabla de procesos de usuario 

18610 * T_SETINS fijar valor en espacio de instrucciones 

18611 * T_SETDATA fijar valor en espacio de datos 

18612 * T_SETUSER fijar valor en tabla de procesos de usuario 

18613 * T_RESUME reanudar ejecución 

18614 *T_EXIT salir 
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18615 * T_STEP activar bit de rastreo 

18616 * 

18617 * Los comandos T_OK y T_EXIT se manejan aquí, y 

18618 * T_RESUME y T_STEP se manejan parcialmente aquí pero la tarea del sistema 

18619 * los completa. El resto corren totalmente por cuenta de la tarea del sistema. 

18620 */ 

18621 

18622 #include "mm.h" 

18623 #include <sys/ptrace.h> 

18624 #include <signal.h> 

18625 #include "mproc.h" 

18626 #include "param.h" 

18627 

18628 #defme NIL MPROC ((struct mproc *) 0) 

18629 

18630 FORWARD _PROTOTYPE( struct mproc *findproc, (pid_t lpid)); 

18631 

18632 /♦========================================= == ======= == 

18633 * do_trace * 

18634 *==============================.- - -- ^ == ==== =============== ===== ========= ===== 

18635 PUBLIC int do_trace() 

18636 { 

18637 register struct mproc *child; 

18638 

18639 /* La llamada T_OK es efectuada por la bifurcación de hijo del depurador antes de 

18640 * que ejecute el proceso por rastrear. 

18641 */ 

18642 if (request == T_OK) {/* hábil, rastreo de este proc por su padre */ 

18643 mp->mp_flags 1= TRACED; 

18644 mm_out.m2_l 2 = 0; 

18645 retum(OK); 

18646 } 

18647 if ((child = fmdproc(pid)) = NIL_MPROC 11 ! (child->mp_flags & STOPPED)) { 

18648 retum(ESRCH); 

18649 } 

18650 /* todas las demás llamadas son efectuadas por la bifurcación de padre del 

18651 * depurador para controlar la ejecución del hijo 

18652 */ 

18653 switch (request) { 

18654 case T EXIT: /* salir */ 

18655 mm_exit(child, (int)data); 

18656 mm_out.m2_12 = 0; 

18657 retum(OK); 

18658 case T RESUME: 

18659 caseT_STEP: /* reanudar ejecución */ 

18660 if (data <011 data> _NSIG) retum(EIO); 

18661 if (data> 0) { /* emitir señal */ 

18662 child->mp_flags &=-TRACED; /* pino desviar señal */ 

18663 sig_proc(child, (int) data); 

18664 child->mp_flags != TRACED; 

18665 } 

18666 child->mp_flags &= -STOPPED; 

18667 break; 

18668 } 

18669 if (sys_trace(request, (int) (child -mproc), taddr, &data) != OK) 

18670 retum(-ermo); 

18671 mm_out.m2_12 = data; 

18672 retum(OK); 

18673 } 
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18675 /*===== === ====== === === == = ====== = === * 

18676 * fmdproc * 

18677 *========== === ===== = ==== = = = === = = = ====== = = = ===== = ==== = */ 

18678 PRIVATE struct mproc *fmdproc(lpid) 

18679 pid_t lpid; 

18680 { 

18681 register struct mproc *rmp; 

18682 

18683 for (rmp = &mproc[INIT_PROC_NR + 1]; rmp < &mproc[NR_PROCS]; rmp++) 

18684 if (rmp->mp_flags & IN_USE && rmp->mp_pid == lpid) retum(rmp); 

18685 retum(NIL_MPROC); 

18686 } 

18688 /*=== ==== == === == === === == == ===== = === * 

18689 * stop_proc * 

18690 " 

18691 

18692 

18693 

18694 

18695 

18696 

18697 

18698 

18699 

18700 

18701 

18702 

18703 

18704 

18705 

18706 

18707 

18708 


PUBLIC void stop_proc(rmp, signo) 
register struct mproc *rmp; 
int signo; 

{ 

/* Un proceso rastreado recibió una señal, así que detenerlo. */ 

register struct mproc *rpmp = mproc + rmp->mp_parent; 

if (sys_trace(-l, (int) (rmp -mproc), 0L, (long *) 0) != OK) retum; 
rmp->mp_flags != STOPPED; 
if (rpmp->mp_flags & WAITING) { 

rpmp->mp_flags &= -WAITING; /* el padre ya no espera */ 
reply(rmp->mp_parent, rmp->mp_pid, 0177 | (signo « 8), NIL_PTR); 

} else { 

rmp->mp_sigstatus = signo; 

} 

} 


src/mm/alloc.c 


18800 /* Este archivo asigna y libera bloques de memoria física de tamaño 

18801 * arbitrario a nombre de las llamadas FORK y EXEC. La estructura de datos 

18802 * clave empleada es la tabla de agujeros, que mantiene una lista de agujeros 

18803 * de memoria, ordenada por dir. de memoria ascendente. Las direcciones 

18804 * que contiene se refieren a memo fís., comenzando en la dir. absoluta 0 

18805 * (no son relativas al principio del MM). Durante la inicialización 

18806 * del sistema, la parte de la memoria que contiene los vectores de int., 

18807 * el kemel y el MM se "asignan" p/marcarlos como no disponibles 

18808 * Y eliminarlos de la lista de agujeros. 

18809 * 

18810 * Los puntos de entrada a este archivo son: 

18811 * alloc_mem: asignar un trozo de memoria del tamaño especificado 

18812 * free_mem: liberar un trozo de memoria previamente asignado 

18813* mem_init: inicializar las tablas cuando MM inicia 

18814* max_hole: devuelve el agujero más grande disponible 

18815 */ 

18816 

18817 #include "mm.h" 

18818 #include <minix/com.h> 


18819 
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18820 #define NR HOLES 128 /*# máx. entradas en tabla de agujeros */ 

18821 #defme NIL_HOLE (struct hole *) 0 

18822 

18823 PRIVATE struct hole { 

18824 phys_clicks h_base; /* ¿dónde comienza el agujero? */ 

18825 phys_clicks h_Ien; /* ¿qué tamaño tiene? */ 

18826 struct hole *h_next; /* apunt a sigte entrada de lista */ 

18827 } hole[NR_HOLES]; 

18828 

18829 

18830 PRIVATE struct hole *hole_head; /* apuntador a 1er agujero */ 

18831 PRIVATE struct hole *free_slots; /* apunt a lista ranuras tabla desocup */ 

18832 

18833 FORWARD _PROTOTYPE( void del_slot, (struct hole *prev_ptr, struct hole *hp) ); 

18834 FORWARD _PROTOTYPE( void merge, (struct hole *hp) 

18835 

18836 

18837 /*========================================= == ============= 

18838 * alloc mem * 

18839 *===-- ^ ==== ===: = = == === = = = == =============== === ============: 

18840 PUBLIC phys_clicks alloc_mem(clicks) 

18841 phys_clicks clicks; /* cantidad de memoria solicitada */ 

18842 { 

18843 /* Asignar un bloque de memoria de la lista libre empleando primer ajuste. El bloque 

18844 * es una secuencia de bytes contiguos, cuya longitud en clics está dada por 

18845 * 'clicks'. Se devuelve un apuntador al bloque. El bloque siempre está en una 

18846 * frontera de clic. Este procedimiento se invoca cuando se requiere memoria 

18847 * para FORK o EXEC. 

18848 */ 

18849 

18850 register struct hole *hp, *prev_ptr; 

18851 phys_clicks old_base; 

18852 

18853 hp = hole_head; 

18854 while (hp l=NIL_HOLE) { 

18855 if (hp->h_Ien >= clicks) { 

18856 /* Se halló un agujero sufic. grande. Usarlo. */ 

18857 old_base = hp->h_base; /* recordar dónde comenzaba */ 

18858 hp->h_base+= clicks; /* arrancarle un trozo */ 

18859 hp->h_Ien-= clicks; /* ídem */ 

18860 

18861 /* Si no se usa todo el agujero, reducir tamaño y regresar. */ 

18862 if (hp->h_Ien 1= 0) retum(old_base); 

18863 

18864 /* Se usó todo el agujero. Manipular lista libre. */ 

18865 del_slot(prev_ptr, hp); 

18866 retum(old_base); 

18867 } 

18868 

18869 prev_ptr = hp; 

18870 hp = hp->h_next; 

18871 } 

18872 retum(NO_MEM); 

18873 } 

18876 /*==== ==== == === == ======= = === = ====== = == = 

18877 * free mem * 

18878 *==== = = = ======== = ====== = === = = = == = ====== = === = == = = = ==== = === = == == 

18879 PUBLIC void free_mem(base, clicks) 
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18880 phys_clicks base; /* dir. base del bloque por liberar */ 

18881 phys_clicks clicks; /* núm. clics por liberar */ 

18882 { 

18883 /* Devolver un bloque de mem libre a la lista de agujeros. Los paráms 

18884 * dicen dónde comienza el bloque en mem fis y su tamaño. El bloque se agrega 

18885 * a la lista de agujerosj si es contiguo a un agujero existente por cualquier 

18886 * extr&mo, se fusiona con el o los agujeros. 

18887 */ 

18888 

18889 register struct hole *hp, *new_ptr, *prev_ptr; 

18890 

18891 if (clicks = 0) retum; 

18892 if ( (new_ptr = free_slots) == NIL_HOLE) panic("Hole table full", NO_NUM); 

18893 new_ptr->h_base = base; 

18894 new_ptr->h_len = clicks; 

18895 free_slots = new_ptr->h_next; 

18896 hp = hole_head; 

18897 

18898 /* Si la dirección de este bloque es numéricamente menor que el agujero más bajo 

18899 * disponible, o si no hay agujeros disponibles, colocar este agujero al frente 

18900 * de la lista de agujeros. 

18901 */ 

18902 if (hp = NILHOLE | | base <= hp->h_base) { 

18903 /* Bloque por liberar va al frente de lista agujeros. */ 

18904 new_ptr->h_next = hp; 

18905 hole_head = new_ptr; 

18906 merge(new_ptr); 

18907 return; 

18908 } 

18909 

18910 /* Bloque por devolver no va al frente de lista de agujeros. */ 

18911 while (hp 1 = NIL_HOLE && base> hp->h_base) { 

18912 prev_ptr = hpj 

18913 hp = hp->h_next; 

18914 } 

18915 

18916 /* Encontramos dónde va. Insertar bloque después de ’prev_ptr'. */ 

18917 new_ptr->h_next = prev_ptr->h_next; 

18918 prev_ptr->h_next = new_ptr; 

18919 merge(prev_ptr); /* el orden es ’p r ev_ptr', ’new_ptr', 'hp' */ 

18920 } 

18923 /*============================================= = ============== 

18924* del Slot * 

18925 * — ■ == — = = ======== = = == ==== == ======== = ====== == =========== = == 

18926 PRIVATE void del slot(prev ptr, hp) 

18927 register struct hole *prev=ptr; /* apunt a entrada aguj. justo adel 'hp' */ 

18928 register struct hole *hp; /* apunt a entrada aguj por eliminar */ 

18929 { 

18930 /* Quitar una entrada de la lista de agujeros. Se invoca este procedo cuando 

18931 * una solicitud de asignar memoria gasta todo un agujero, lo que reduce 

18932 * el núm de agujeros y requiere la eliminación de una entrada 

18933 * de la lista de agujeros. 

18934 */ 

18935 

18936 if (hp = hole_head) 

18937 hole_head = hp->h_next; 

18938 else 

18939 prev_ptr->h_next = hp->h_next; 
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18940 

18941 hp->h_next = free_slots; 

18942 free_slots = hp; 

18943 } 

18946 /*===== === ====== === === == = ====== = === * 

18947 * merge * 

18948 *== = = = ===== = = = === = = = == = == = = = = ===== === = == = ====== == == = = = == = = = = = = = */ 

18949 PRIVATE void merge(hp) 

18950 register struct hole *hp; /* apunt a agujero p/fusionar con suceso */ 

18951 { 

18952 /* Ver si hay agujeros contiguos y fusionarlos si se hallanj pueden ocurrir 

18953 * cuando se libera un bloque de memoria y está junto a otro agujero 

18954 * por cualquier extremo, o ambos, 'hp' apunta al primero de una serie 

18955 * de tres agujeros que quizá podrían fusionarse. 

18956 */ 

18957 

18958 register struct hole *next_ptr; 

18959 

18960 /* Si 'hp' apunta al últ. agujero, no hay fusión posible. Si no, 

18961 * tratar de absorber en él su sucesor y liberar la entrada de tabla del sucesor. 

18962 */ 

18963 if ( (next_ptr = hp->h_next) = NILHOLE) retum; 

18964 if (hp->h_base + hp->h_len = next_ptr->h_base) { 

18965 hp->h_len += next_ptr->h_len; /* El lero obtiene mem del 20 */ 

18966 del_slot(hp, next_ptr); 

18967 } else { 

18968 hp = next_ptr; 

18969 } 

18970 

18971 /* Si 'hp' ahora apunta al último agujero, regresar¡ si no, tratar 

18972 * de absorber al sucesor. 

18973 */ 

18974 if ( (next_ptr = hp->h_next) = NIL HOLE) retum; 

18975 if (hp->h_base + hp->h_len = next_ptr->h_base) { 

18976 hp->h_len += next_ptr->h_len; 

18977 del_slot(hp, next_ptr); 

18978 } 

18979 } 


18983 * max_hole 

18984 *============== = ============== == = 

18985 PUBLIC phys_clicks max_hole() 

18986 { 

18987 /* Examinar lista de agujeros y devolver el más grande. */ 

18988 

18989 register struct hole *hp; 

18990 register phys_clicks max; 

18991 

18992 hp = hole_head; 

18993 max = 0; 

18994 while (hp != NIL HOLE) { 

18995 if (hp->h_len > max) max = hp->h_len; 

18996 hp = hp->h_next; 

18997 } 

18998 retumfmax); 

18999 } 
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19002 /♦==== ====== === ======= = ===== = = = == = ==== ♦ 

19003 * mem_init * 

19004 *== = === = ===== = ======= = ======= == = = === = == = ====== == == = ======== == */ 

19005 PUBLIC void mem_init(total, free) 

19006 phys_clicks *total, *free; /* resúmenes de tamaño de memoria */ 

19007 { 

19008 /* Inicializar listas de agujeros. Hay dos: ’hole_head' apunta a una lista 

19009 * enlazada de todos los agujeros (mem desocupada) del sistema; ’free_slots' 

19010 * apunta a una lista enlazada de entradas de tabla no en uso. Al principio, 

19011 * la primera lista tiene 1 entrada p/trozo de mem física, y la 2a. enlaza 

19012 * las ranuras de tabla restantes. Al fragmentarse la memoria con el tiempo 

19013 * (los agujeros grandes iniciales se dividen en agujeros más chicos), 

19014 * se requieren más ranuras de tabla p/representarlos. Estas ranuras se toman 

19015 * de la lista encabezada por 'free_slots'. 

19016 */ 

19017 

19018 register struct hole *hp; 

19019 phys_clicks base; /* dirección base del trozo */ 

19020 phys_clicks size; /* tamaño del trozo */ 

19021 message mess; 

19022 

19023 /* Poner todos los agujeros en la lista libre. */ 

19024 for (hp = &hole[0]; hp < &hole[NR_HOLES]; hp++) hp->h_next = hp + 1; 

19025 hole[NR_HOLES-11 .h next = NIL HOLEj 

19026 hole head = NIL HOLE; 

19027 free_slots = &hole[0]; 

19028 

19029 /* Pedir al kernel trozos de memoria física y asignar un agujero a c/u. La llamada 

19030 * SYS_MEM responde con la base y el tamaño del siguiente trozo 

19031 * Y la cantidad total de memoria. 

19032 */ 

19033 *free = 0; 

19034 for (;;) { 

19035 mess.m type = SYS MEM; 

19036 if (sendrec(SYSTASK, &mess) != OK) panic("bad SYS MEM?", NO_NUM); 

19037 base = mess.ml_il; 

19038 size = mess.ml i2; 

19039 if (size = 0)-break; /* ¿no hay más? */ 

19040 

19041 free_mem(base, size); 

19042 *total = mess.ml_i3; 

19043 *free += size; 

19044 } 

19045 


} 
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19100 /* Este archivo contiene algunas rutinas de utilería para MM. 

19101 * 

19102 * Los puntos de entrada son: 

19103 * allowed: ver si se permite un acceso 

19104 * no_sys: se llama si el núm de llamada al sistema no es válido 

19105 * panic: MM encontró un error fatal y no puede continuar 

19106 * tell_fs: interfaz con el sistema de archivos 

19107 */ 

19108 

19109 #include "mm.h" 

19110 #include <sys/ stat.h> 

19111 #include <minix/callnr.h> 

19112 #include <minix/com.h> 

19113 #include <fcntl.h> 

19114 #include <signal.h> /* sólo porque mproc.h la necesita */ 

19115 #include "mproc.h" 

19116 

19117 /*==== = = = = == = = = = === == = = = = == = === = = == === = == = = == 

19118 * allowed 

19119 *============ = =========== ============== 

19120 PUBLIC int allowed(name_buf, s_buf, mask) 

19121 char *name_buf; /* apunto a nombre arch. por EXECutar */ 

19122 struct stat *s_buf; /* buffer p/crear y devolver struct stat*/ 

19123 int mask; /* R BIT, W_BIT o XBIT */ 

19124 { 

19125 /* Ver si puede accederse al archivo. Devolver EACCES o ENOENT si acceso prohibido. 

19126 * Si es legal, abrir archivo y devolver descriptor de archivo. 

19127 */ 

19128 

19129 int fd; 

19130 int save_ermo; 

19131 

19132 /* Aprovechar que la máscara de access() es igual a la de permisos. P.ej. X_BIT 

19133 * en <minix/const.h> es igual a X_OK en <unistd.h> y S_IXOTH en <sys/stat.h>. 

19134 * tell_fs(DO_CHDIR,...) igualó los ids reales de MM a los ids efectivos 

19135 * del usuario, así que access() funciona bien para programas setuid. 

19136 */ 

19137 if (access(name_buf, mask) < 0) retum(-ermo); 

19138 

19139 /* Archivo accesible pero tal vez no legible. Hacerlo legible. */ 

19140 tell_fs(SETUID, MM_PROC_NR, (int) SUPERUSER, (int) SUPERUSER); 

19141 

19142 /* Abrir arch. y aplicarle fstat. Restaurar ids pronto p/manejar errores. */ 

19143 fd = open(name_buf, ORDONLY); 

19144 save_errno = ermo; /* open podría fallar, p.ej. de ENFILE */ 

19145 tell_fs(SETUID, MM PROC NR, (int) mp->mp_effiiid, (int) mp->mp_effuid); 

19146 if (fd < 0) retum(-save_ermo); 

19147 if (fstat(fd, s_buf) < 0) panic("allowed: fstat failed", NOJSÍUM); 

19148 

19149 /* Sólo pueden ejecutarse archivos normales. */ 

19150 if (mask = X BIT && (s_buf->st_mode & I TYPE) != I REGULAR) { 

19151 close(fd); 

19152 retum(EACCES); 

19153 } 

19154 retum(fd); 
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19155 } 

19158 /*============================================= = ========= 

19159* no_sys * 

19160 *============================= == =============== == ======= == 

19161 PUBLIC int no_sys() 

19162 { 

19163 /* Se solicitó un número de llamada al sistema no implementado por MM. */ 19164 

19165 retum(EINVAL); 

19166 } 

19169 /*============================================== = ========= 

19170* panic * 

19171 *==== ==- = ^ === ^ ====== =.^= ======================= == ====== ==: 

19172 PUBLIC void panic(format, num) 

19173 char *format; /* cadena de formato */ 

19174 int num; /* núm que va con cadena de foro */ 

19175 { 

19176 /* Algo terrible sucedió. Se causan pánicos cuando se detecta una inconsistencia 

19177 * intema, p.ej., un error de programación o un valor no permitido 

19178 * de una constante definida. 

19179 */ 

19180 

19181 printf("Memory manager panic: %s ", format); 

19182 if (num != NO_NUM) printf("%d",num); 

19183 printf("\n"); 

19184 tell_fs(SYNC, 0, 0, 0); /* vaciar el caché al disco */ 

19185 sysabort(RBTPANIC); 

19186 } 

19189 /*============================================== = ========= 

19190* tell_fs * 

19191 *== = ========================== == =============== === ====== == 

19192 PUBLIC void tell_fs(what, pl, p2, p3) 

19193 int what, pl, p2, p3; 

19194 { 

19195 /* MM sólo usa esta rutina para informar al FS de ciertos eventos: 

19196 * tell_fs(CHDIR, slot, dir, 0) 

19197* tell_fs(EXEC, proc, 0, 0) 

19198* tell_fs(EXIT, proc, 0, 0) 

19199 * tell_fs(FORK, parent, child, pid) 

19200 * tell_fs(SETGID, proc, realgid, effgid) 

19201 * tell_fs(SETSID, proc, 0, 0) 

19202 * tell_fs(SETUID, proc, realuid, effuid) 

19203 * tell_fs(SYNC, 0, 0, 0) 

19204 * tell_fs(UNPAUSE, proc, signr, 0) 

19205 */ 

19206 

19207 message m; 

19208 

19209 m.ml_il =pl; 

19210m.ml_i2 = p2; 

19211 m.ml_i3 = p3; 

19212_taskcall (FS_PROC_NR , what, &m); 

19213 } 
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19300 

19301 ’ 

19302 ! 

19303 = 

19304 

19305 

19306 

19307 

19308 

19309 

19310 

19311 

19312 

19313 

19314 

19315 

19316 


1 * Ocasionalmente, MM debe exhibir mensajes. Usa la rutina de biblioteca 
estándar printk(). (El nombre "printf' realmente es una maGro definida como 
"printk".) La exhibición se logra invocando la tarea TTY directamente, 
no pasando por el FS. 


#include "mm.h" 
#include <minix/com.h> 


#define BUFSIZE 


1 * exhibir tamaño de buffer *1 


PRIVATE int buf_count; 1 *# caracteres en buffer *1 

PRIVATE char print_buf[BUF_SIZE]; 1 * buffer de salidas aquí *1 
PRIVATE message putch msg; 1 * sirve para mensaje a tarea TTY *1 


_PROTOTYPE( FORWARD void flush, (void)); 


19317 1 *======================================= 

19318 * putk 

19319 *======================================== 

19320 PUBLIC void putk(c) 

19321 int C; 

19322 { 

19323 /* Acumular otro carácter. Si 0 o buffer lleno, exhibirlo. *1 

19324 

19325 if (c = 0 II buf_count = BUF SIZE) flush(); 

19326 if (c = ’ \ n ’) putk(’ \ r ’); 

19327 if (c != 0) print_buf[buf_count++] = c; 

19328 } 

19331 /*================== == =============== 

19332 * flush 

19333 *================================================================*7 

19334 PRIVATE void flush() 

19335 { 

19336 1 * Vaciar el buffer de exhibición invocando la tarea TTY. *1 

19337 

19338 if (buf_count = 0) retumj ; 

19339 putch_msg.m_type = DEVWRITE; 

19340 putchmsg.PROCNR =0; 

19341 putchmsg.TTYLINE = 0; 

19342 putch_msg.ADDRESS =print_buf; 

19343 putch msg.COUNT = buf count; 

19344 sendrec(TTY, &putch_msg); 

19345 buf count = 0; 

19346 } 
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19400 /* Cabecera maestra del FS. Incluye algunos otros archivos 

19401 * y define las constantes principales. 

19402 */ 

19403 #defmePOSIX SOURCE 1 /* decir cabeceras q/incl. cosas POSIX */ 

19404 #define -MINIX- 1 /* decir cabeceras q/incl. cosas MINIX */ 

19405 #defme =SYSTEM 1 /* decir cabeceras q/éste es el kemel */ 

19406 

19407 /* Lo siguiente es tan básico que todos los archivos *.c lo incluyen autom. */ 

19408 #include <minix/config.h>/* DEBE ser primero */ 

19409 #include <ansi.h> /* DEBE ser segundo */ 

19410 #include <sys/types.h> 

19411 #include <minix/const.h> 

19412 #include <minix/type.h> 

19413 

19414 #include <limits.h> 

19415 #include <ermo.h> 

19416 

19417 #include <minix/ syslib.h> 

19418 

19419 #include "const.h" 

19420 #include "type.h" 

19421 #include "proto.h" 

19422 #include "glo.h" 
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19500 

19501 

19502 

19503 

19504 

19505 

19506 

19507 

19508 

19509 

19510 

19511 

19512 * 

19513 * 

19514 

19515 

19516 

19517 

19518 

19519 

19520 

19521 

19522 

19523 

19524 


/* Tamaños de tablas */ 

#define Vl_NR_DZONES 
#define Vl_NA_TZONES 
#define V2 NR DZONES 
#defme V2=NR=TZONES 

#define NRFILPS 
#define NRINODES 
#defme NRSUPERS 
#defme NRLOCKS 


/* # núms. zona directos en nodo-i VI */ 
/* # núms. zona totales en nodo-j VI */ 
/* # núms. zona directos en nodo-i V2 */ 
/* # núms. zona totales en nodo-i V2 */ 

/* # ranuras en tabla filp */ 

/* # rano en tabla nodos-i "en núcleo" */ 
/* # ranuras en tabla superbloques */ 

/* # rano en tabla candados de archivo */ 


/* El tipo de sizeof puede ser (unsigned) long. Use la sigte macro p/tomar 
tamaños de objetos pequeños pique no haya sorpresas como el paso 
de constantes (small) long a rutinas que esperan un int. 

#defme usizeof(t) ((unsigned) sizeof(t)) 


/* Tipos de sistemas de archivos. */ 
#define SUPER MAGIC 0x137F 

#define SUPER=REV 0x7F13 
#defme SUPER_V2 0x2468/* n 
#defme SUPEA_V2_REV 


0x6824/* V2 mágico es 


/* núm mágico contenido en superbloque */ 

/* # mágico si disco 68000 leído en PC o w * 
n mágico p/sistemas de archivos V2 */ 


nPC leído en 68K o v 


#defme VI 
#define V2 


n versión de sistemas de arch. VI */ 
n versión de sistemas de arch. V2 */ 
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19525 

19526 

19527 

19528 

19529 

19530 

19531 

19532 

19533 

19534 

19535 

19536 

19537 

19538 

19539 

19540 

19541 

19542 

19543 

19544 

19545 

19546 

19547 

19548 

19549 

19550 

19551 

19552 

19553 

19554 

19555 

19556 

19557 

19558 

19559 

19560 
arranque */ 

19561 

superbloque */ 

19562 

19563 

19564 
dir/bloque 

19565 
*/ 


/* Constantes diversas. */ 


#defme SUUID 
#defme SYSJJID 
#defme SYS_GID 
#define NORMAL 
#define NOREAD 
#define PREFETCH 


((uid_t) 0) /* uid_t del superusuario */ 

((uid_t) 0) /* uid_t de procesos MM e INIT */ 

((gid_t) 0) /* gid t de procesos MM e INIT */ 

0 /* hace que get_block lea disco */ 

1 /* impide que get_block lea disco */ 

2 /* dice a get_block no lea ni marque dev */ 


#defme XPIPE 
#defme XOPEN 
#defme XLOCK 


(-NR_TASKS-1) /* usado en fp_task si susp en conducto */ 

(-NRTASKS-2) /* usado en fp_task si susp en abrir */ 

(-NR_TASKS-3) /* usado en fp_task si susp en candado */ 

#define XPOPEN (-NR_TASKS-4) /* usado en fp_task si susp en abrir cond */ 


#defíne NO_BIT ((bit_t) 0) /* devuelto por alloc_bit() si fracasó */ 


#defíne DUP MASK 0100 /* máscara p/distinguir dup2 y dup */ 


#defme LOOK UP 0 

#defme ENTER 1 

#defme DELETE 2 

#defme IS_EMPTY 3 


/* dice search_dir busque cadena */ 

/* dice search_dir cree entrada dir */ 

/* dice search_dir borre entrada */ 

/* dice search dir dev. OK o ENOTEMPTY */ 


#define CLEAN 
#define DIRTY 
#defme ATIME 
#defme CTIME 
#defme MTIME 


0 /* copias en disco y memoria idénticas */ 

1 /* copias en disco y memoria difieren */ 

002 /* 1 si campo atime debe actualizarse */ 

004 /* 1 si campo ctime debe actualizarse */ 

010 /* 1 si campo mtime debe actualizarse */ 


#defme BYTE_SWAP 0 /* dice a conv2/conv4 q/interc. bytes */ 

#defíne DONT_SWAP 1 /* dice a conv2/conv4 q/no interc. bytes */ 


#define END OF FILE (-104) /* eof detectado */ 


#define ROOT_INODE 1 /* # nodo-i p/directorio raíz */ 

#defme BOOTBLOCK 


((block_t) 0) /* # bloque de bloque de 


#define SUPER BLOCK ((block t) 1) /* # bloque de 


#defme DIRENTRYSIZE 
#define NRDIRENTRIES 

*/ 

#defme SUPER SIZE 


usizeof (stmct direct)/* # bytes/entr dir 
(BLOCKSIZE/DIRENTRYSIZE)/* 

usizeof (struct super_block)/* tamaño 


# entr 
superbloq 


19566 #defme PIPE SIZE (Vl_NR_DZONES*BLOCK_SIZE)/* 

conducto, bytes */ 

19567 #defme 

BITMAP CHUNKS (BLOCK SIZE/usizeof (bitchunk t))/* # trozos mapa/blq */ 


19568 

19569 

19570 

19571 

19572 

zonas/blq indir */ 

19573 

19574 

19575 

19576 

19577 

19578 

zonas/blq indir */ 

19579 

19580 

19581 


/* Tamaños derivados correspondientes al sist. archivos VI. */ 

#defme V1_Z0NE_NUM_SIZE usizeof (zonel_t)/* # bytes en zona VI */ 

#defíne Vl_INODE_SIZE usizeof (di_inode) /* bytes en nodo-i V1 */ 

#define V1INDIRECTS (BLOCK_SIZE/V1_ZONE_NUM_SIZE) /* # 

#defme Vl_INODES_PER_BLOCK (BLOCK_SIZE/Vl_INODE_SIZE)/* # nodos-i Vl/blq 


/* Tamaños derivados correspondientes al sist. archivos V2. */ 

#defme V2_Z0NE_NUM_SIZE usizeof (zone_t)/* # bytes en zona V2 */ 

#defíne V2_INODE_SIZE usizeof (d2_inode) /* bytes en nodo-i V2 */ 

#define V2INDIRECTS (BLOCK_SIZE/V2_ZONE_NUM_SIZE) /* # 

#defme V2_INODES_PER BLOCK (BLOCK_SIZE/V2_INODE_SIZE)/* # nodos-i V2/blq */ 


#defíne printf printk 
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19600 

19601 

19602 

19603 

19604 

19605 

19606 

19607 

19608 

19609 

19610 

19611 

19612 

19613 

19614 

19615 

19616 

19617 

19618 

19619 

19620 

19621 

19622 


1 * Declaración del nodo-i VI en disco (no en el núcleo). *1 

typedef struct { 1 * nodo-i de disco VI .x *1 
mode.t di mode; 1 * tipo archivo, protección, etc. *1 

uid t di uid; 1 * id usuario de dueño del archivo *1 

off-t dl-size; /* tamaño archivo actual en bytes *1 

time t di mtime; 1 * último cambio a datos del arch. *1 

gid_t dl_Qid; 1 * número de grupo *1 

nlink t di nlinks; 1 * cuántos vinculas a este archivo *1 

U16_t-dl_ZOne[Vl_NR_TZONESJ; 1 * núms blq p/directo, ind y dob ind *1 
} dl_inode; 


1 * Declaración del nodo-i V2 e: 

mode t d2 mode; 
ul6 t d2 ñlinks; 
uid-t d2-uid; 

U16-t d2-gid; 
off-t d2-size; 
time t d2 atime; 


zone=t d2=zone[V2_NR_TZONESJ; 1 
} d2_inode; 


disco (no en el núcleo). *1 

typedef struct { 1 * nodo-i de disco V2.x 
1 * tipo archivo, protección, etc. *1 
1 * cuántos vínculos al arch. iHACK! *1 
1 * id usuario de dueño del archivo */ 

/* número de grupo. iHACK! *1 
1 * tamaño archivo actual en bytes *1 
1 * último acceso a datos del arch. *1 
1 * último cambio a datos del arch. *1 
1 * último cambio a datos del nodo-i *1 
blq p/directo, ind y dob ind *1 
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19700 1 * Prototipos de funciones. *1 

19701 

19702 1 * Structs empleados en prototipos deben declararse como tales primero. *1 19703 si 

19704 struct filp. 

19705 struct inode; 

19706 struct super_block; 

19707 

19708 1 * cache.c *1 

19709_PROTOTYPE( zone_t alloc_zone, (Dev_t dev, zone_t z) 

19710 

flushall, (Dev t dev) 

19711 

free_zone, (Dev_t dev, zone_t numb) 

19712 _PROTOTYPE( struct buf *get_block, (Dev_t dev, block_t block,int only_search»; 

19713 

invalídate, (Dev_t device) 

19714_PROTOTYPE( void put_block, (struct buf *bp, int blockjype) 

19715 

rw_block, (struct buf *bp, int rw_flag) 

19716_PROTOTYPE( void rw_scattered, (Dev t dev, 

19717 

struct buf **bufq, int bufqsize, int rw_flag) 

19718 

19719 1 * device.c *1 

19720 _PROTOTYPE( void call_task, (int task_nr, message *mess_ptr) 

19721 

dev_opcl, (int task_nr, message *mess_ptr) 

19722 _PROTOTYPE( int dev_io, (int rw_flag, int nonblock, Dev_t dev, 

19723 

off_t pos, int bytes, int proc, char *buff) 

19724 
(void) ); 


); 

_PROTOTYPE( 

); 

_PROTOTYPE( 

); 

_PROTOTYPE( 


); 


_PROTOTYPE( 

); 


); 

_PROTOTYPE( 

); 


); 

_PROTOTYPE( int 


void 

void 


void 




void 


do_ioctl, 
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19725 _PROTOTYPE( void no_dev, (int task nr, message *m_ptr) ); 

19726 _PROTOTYPE( void call_ctty, (int task_nr, message *mess_ptr) ); 

19727 _PROTOTYPE( void tty_open, (int task_nr, message *mess_ptr) ); 

19728 _PROTOTYPE( void ctty_close, (int task_nr, message *mess_ptr) ); 

19729 _PROTOTYPE( void ctty_open, (int task_nr, message *mess_ptr) ); 

19730 _PROTOTYPE( int do_setsid, (void) ); 

19731 #if ENABLENETWORKING 

19732 _PROTOTYPE( void net_open, (int task_nr, message *mess_ptr) ); 

19733 #else 

19734 #define net_open 0 

19735 #endif 

19736 

19737 /* Hiedes.c */ 


19738 _PROTOTYPE( stmct ftlp *find_filp, (stmct inode *rip, Mode_t bits) ); 

19739 _PROTOTYPE( int get_fd, (int start, Mode_t bits, int *k, struct filp **fpt)); 

19740 _PROTOTYPE( stmct filp *get_filp, (int fild) ); 

19741 

19742 /* inode.c */ 

19743 _PROTOTYPE( stmct inode *alloc_inode, (Dev_t dev, Mode_t bits) ); 

19744 _PROTOTYPE( void dup_inode, (stmct inode *ip) ); 

19745 _PROTOTYPE( void free inode, (Dev t dev, Ino t numb) ); 

19746 _PROTOTYPE( stmct inode *get_inode, (Dev_t dev, int numb) ); 

19747 _PROTOTYPE( void put_inode, (stmct inode *rip) ); 

19748 _PROTOTYPE( void update_times, (stmct inode *rip) ); 

19749 _PROTOTYPE( void rw_inode, (stmct inode *rip, int rw_flag) ); 

19750 _PROTOTYPE( void wipe_inode, (stmct inode *rip) ); 

19751 

19752 /* link.c */ 

19753 _PROTOTYPE( int do_link, (void) ); 

19754 _PROTOTYPE( int do_unlink, (void) ); 

19755 _PROTOTYPE( int do_rename, (void) ); 

19756 _PROTOTYPE( void trúncate, (stmct inode *rip) ); 

19757 

19758 /* lock.c */ 

19759 _PROTOTYPE( int lock_op, (stmct filp *f int req) ); 

19760 _PROTOTYPE( void lock revive, (void) ); 

19761 

19762 /* main.c */ 

19763 _PROTOTYPE( void main, (void) ); 

19764 _PROTOTYPE( void reply, (int whom, int result) ); 

19765 

19766 /* misc.c */ 

19767 _PROTOTYPE( int do_dup, (void) ); 

19768 _PROTOTYPE( int do_exit, (void) ); 

19769 _PROTOTYPE( int do_f.cntl, (void) ); 

19770 _PROTOTYPE( int do_fork, (void) ); 

19771 _PROTOTYPE( int do_exec, (void) ); 

19772 _PROTOTYPE( int do_revive, (void) ); 

19773 _PROTOTYPE( int do set, (void) ); 

19774 _PROTOTYPE( int do_sync, (void) ); 

19775 

19776 /* mount.c */ 

19777 _PROTOTYPE( int do_mount, (void) ); 

19778 _PROTOTYPE( int do_umount, (void) ); 

19779 

19780 /* open.c */ 

19781 _PROTOTYPE( int do_clase, (void) ); 

19782 _PROTOTYPE( int do_creat, (void) ); 

19783 _PROTOTYPE( int dojseek, (void) ); 

19784 _PROTOTYPE( int do_mknod, (void) ); 
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19785 _PROTOTYPE( int do mkdir, (void) ); 

19786 _PROTOTYPE( int do_open, (void) ); 

19787 

19788 /* path.c */ 

19789 _PROTOTYPE( struct inode *advance, (struct inode *dirp, char string[NAME_MAX])); 

19790 _PROTOTYPE( int search_dir, (struct inode *ldir_ptr, 

19791 char string [NAMEJVIAX], ino_t *numb, int flag) ); 

19792 _PROTOTYPE( struct inode *eat_path, (char *path) ); 

19793 _PROTOTYPE( struct inode *last_dir, (char *path, char string [NAME_MAX])); 

19794 

19795 /* pipe.c */ 

19796 _PROTOTYPE( int do_pipe, (void) ); 

19797 _PROTOTYPE( int do_unpause, (void) ); 

19798 _PROTOTYPE( int pipe_check, (struct inode *rip, int rw_flag, 

19799 int oflags, int bytes, off_t position, int *canwrite)); 

19800 _PROTOTYPE( void release, (struct inode *ip, int call_nr, int count) ); 

19801 _PROTOTYPE( void revive, (int proc_nr, int bytes) ); 

19802 _PROTOTYPE( void suspend, (int task) ); 

19803 

19804 /* protect.c */ 

19805 _PROTOTYPE( int do_access, (void) ); 

19806 _PROTOTYPE( int do_chmod, (void) ); 

19807 _PROTOTYPE( int do_chown, (void) ); 

19808 _PROTOTYPE( int do_umask, (void) ); 

19809 _PROTOTYPE( int forbidden, (struct inode *rip, Mode_t access_desired) ); 

19810 _PROTOTYPE( int read_only, (struct inode *ip) ); 

19811 

19812 /* putk.c */ 

19813 _PROTOTYPE( void putk, (inte) ); 

19814 

19815 /* read.c */ 

19816 _PROTOTYPE( int do read, (Yoid) ); 

19817 _PROTOTYPE( struct buf *rahead, (struct inode *rip, block_t baseblock, 

19818 off_t position, unsigned bytes_ahead) ); 

19819 _PROTOTYPE( void read_ahead, (void) ); 

19820 _PROTOTYPE( block_t read_map, (struct inode *rip, off_t position) ); 

19821 _PROTOTYPE( int read_write, (int rw_flag) ); 

19822 _PROTOTYPE( zone_t rd_indir, (struct buf *bp, int índex) ); 

19823 

19824 /* stadir.c */ 

19825 _PROTOTYPE( int do_chdir, (void) ); 

19826 _PROTOTYPE( int do_chroot, (void) ); 

19827 _PROTOTYPE( int do fstat, (void) ); 

19828 _PROTOTYPE( int do_stat, (void) ); 

19829 

19830 /* super.c */ 

19831 _PROTOTYPE( bit_t alloc_bit, (struct super_block *sp, int map, bit_t origin»); 

19832 _PROTOTYPE( void íree_bit, (struct super_block *sp, int map, 

19833 bit t bit_retumed) ); 

19834 _PROTOTYPE( struct super_block *get_super, (Dev_t dev) ); 

19835 _PROTOTYPE( int mounted, (struct inode *rip) ); 

19836 _PROTOTYPE( int read_super, (struct super_block *sp) ); 

19837 

19838 /* time.c */ 

19839 _PROTOTYPE( int do_stime, (void) ); 

19840 _PROTOTYPE( int do_time, (void) ); 

19841 _PROTOTYPE( int do_tims, (void) ); 

19842 _PROTOTYPE( int do_utime, (void) ); 

19843 

19844 /* utility.c */ 
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19845 _PROTOTYPE( time tclock time, (void) ); 

19846 _PROTOTYPE( unsigned conv2, (int narro, int w) ); 

19847 _PROTOTYPE( long conv4, (int narro, long x) ); 

19848 _PROTOTYPE( int fetch_name, (char *path, int len, int flag) ); 

19849 _PROTOTYPE( int no sys, (void) ); 

19850 _PROTOTYPE( void panic, (char *format, int num) ); 

19851 

19852 /* write.c */ 

19853 _PROTOTYPE( void clear_zone, (struct inode *rip, off_t pos, int flag) ); 

19854 _PROTOTYPE( int do_write, (void) ); 

19855 _PROTOTYPE( struct buf *new_block, (stmct inode *rip, off_t position) ); 

19856 _PROTOTYPE( void zero_block, (struct buf *bp) ); 


19900 

19901 

19902 

19903 

19904 

19905 

19906 

19907 

19908 

19909 

19910 

19911 

19912 

19913 

19914 

19915 

19916 

19917 

19918 

19919 

19920 

19921 

19922 

19923 

19924 

19925 

19926 

19927 

19928 


/* EXTERN debe ser extern excepto para el archivo de tabla */ 

#ifdef_TA8LE 
#undef EXTERN 
#defme EXTERN 
#endif 

/* Variables globales del sistema de archivos */ 

EXTERN stmct fproc *fp; /* apunto a stmct fproc de invocador */ 

EXTERN int super_user; /* 1 si invocador es supemsuario */ 

EXTERN int dont_reply; /* narro. 0; 1 p/inhibir respuesta */ 

EXTERN int susp_count; /* # procesos suspendidos en conducto */ 
EXTERN int nr locks; /* # candados puestos actualmente */ 

EXTERN int reviving; /* # procesos de conducto por revivir */ 

EXTERN off t rdahedpos;/* posición p/lectura anticipada */ 

EXTERN stmct inode *rdahed_inode; /* apunto a nodo-i p/lect. antic. */ 

/* Los parámetros de la llamada se guardan aquí. */ 

EXTERN message m; /* el mensaje de entrada mismo */ 

EXTERN message mi; /* mensaje de salida p/responder */ 

EXTERN int who; /* núm proceso del invocador */ 

EXTERN int fs_call; /* número de llamada al sistema */ 

EXTERN char user_path[PATH_MAX]; /* espacio p/nombre mta usuario */ 

/* Estas variables sirven para devolver resultados al invocador. */ 

EXTERN int err_code; /* almac. temp. p/número de error */ 

EXTERN int rdwt_err; /* situac. de últ. solic. E/S disco */ 

/* Datos que requieren inicialización. */ 

extern _PROTOTYPE (int (*call vector[]), (void)); /* tabla llamo al sist. */ 


19929 extern int max_major; /* dispositivo princ. máx (+1) */ 

19930 extern char dotl [2]; /* dotl (&dotl [0]) y dot2 (&dot2[0]) tienen signif. */ 

19931 extern char dot2[3]; /* especial p/search_dir: no verif. perro acceso. */ 
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20000 

/* Ésta es la información por proceso. Se reserva 1 ranura picada proceso potencial. 

20001’ 

* Así, NR PROCS debe ser igual que < 

sn el kemel. No es posible 

20002’ 

N ni necesario saber aquí si una ranura 

está libre. 

20003 

*/ 


20004 



20005 



20006 

EXTERN struct fproc { 


20007 

mode t fp umask; 

/* máscara fijada por la llamada umask */ 

20008 

struct inode *fp workdir; 

/* apunt al nodo-i del dir de trabajo */ 

20009 

struct inode *fp rootdir; 

/* apunt al dir raíz actual (ver chroot) */ 

20010 

struct filp *fp filpíOPEN MAX1;/* tabla de descriptores de archivo */ 

20011 

uid t fp realuid; 

/* id de usuario real */ 

20012 

uid tfjj effiiid; 

/* id de usuario efectivo */ 

20013 

gid t fp realgid; 

/* id de grupo real */ 

20014 

gid tfp effgid; 

/* id de grupo efectivo */ 

20015 

dev t fp ttv; 

/* princ/secund de tty controladora */ 

20016 

int fp fd; 

/* guardar fd si rd/wr no puede acabar */ 

20017 

char *fp buffer; 

/* guardar buf si rd/wr no puede acabar */ 

20018 

int fp nbytes; 

/* guard bytes si rd/wr no puede acabar */ 

20019 

int fp cum io partial; 

/* cta bytes si rd/wr no puede acabar */ 

20020 

char fp suspended; 

/* 1 si proceso suspendido esperando */ 

20021 

char fp revived; 

/* 1 si proceso se va a revivir */ 

20022 

char fp task; 

/* qué tarea espera el proceso */ 

20023 

char fp sesldr; 

/* 1 si proceso es jefe de sesión */ 

20024 

pid t fp pid; 

/* id de proceso */ 

20025 

long fp cloexec; 

/* mapa bits p/tabla 6-2 POSIX FD CLOEXEC */ 

20026 

} fproc [NR PROCS]; 


20027 



20028 

/* Valores de campos. */ 


20029#defme NOT SUSPENDED 0 

/* proc no suspendido en conducto o tarea */ 

20030 

#define SUSPENDED 1 

/* proc suspendido en conducto o tarea */ 

20031 

#defme NOT REVIVING 0 

/* el proc no está siendo revivido */ 

20032 

#define REVIVING 1 

/* se revive al proceso en suspensión */ 

src/fs/buf.h 


20100 /* Caché de buffers (bloques). Para adquirir un bloque, una rutina invoca 

20101 * get_block(), y le dice cuál quiere. El bloque ahora está "en uso" 

20102 * Y se incrementa su campo ’b_count'. Los bloques no en uso 

20103 * se encadenan en una lista LRU; ’front' apunta al bloque menos 

20104 * recientemente usado, y ’rear', al más recientemente usado. 

20105 * También se mantiene una cadena inversa usando el campo b_prev. El uso 

20106 * para LRU se mide por el momento en que put_block() acaba. El 20. 

20107 * parámetro de put_block() puede violar el orden LRU y poner un bloque 

20108 * a la cabeza de la lista, si es probable que no se necesitará pronto. 

20109 * Si un bloque se modifica, la rutina que lo haga debe asignar DIRTY a b_dirt 

20110 * para que el bloque se reescriba finalmente en disco. 

20111 */ 

20112 

20113 #include <sys/dir.h> /* necesita struct direct */ 

20114 
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20115 

20116 

20117 

20118 

20119 

20120 
20121 
20122 

20123 

20124 

20125 

20126 

20127 

20128 

20129 

20130 

20131 

20132 

20133 

20134 

20135 

20136 

20137 

20138 

20139 

20140 

20141 

20142 

20143 

20144 
20146 

20150 

20151 

20152 

20153 

20154 

20155 

20156 

20157 

20158 

20159 

20160 
20161 
20162 

20163 

20164 

20165 

20166 

20167 

20168 


EXTERN struct buf { 

/* Porción de datos del buffer */ 

char b—data[BLOCK_SIZE]; /* datos de usuario ordinarios */ 

struct direct b dir[NRDIRENTRIES]; /* bloque de directorio */ 

zonel t b vi ind[Vl INDIRECTS]; /* bloque de indirección VI */ 

zone_t b=v2=ind[V2=INDIRECTS]; /* bloque de indirección V2 */ 

dljnode b-vl_ino[Vl_INODES_PER_BLOCK]; /* bloque de nodos-i VI */ 
d2_inode b-v2_ino[V2_INODES_PER_BLOCK]; /* bloque de nodos-i V2 */ 
bitchunk t b-bitmap[BITMAP_CHUNKS] ; /* bloque de mapa de bits */ 

¡b: 


/* Porción de cabecera del buffer. */ 

struct buf *b_next; 

struct buf *b_prev; 

struct buf *b_hash; 

block_t b_blocknr; 

dev_t b_dev; 

char b_dirt; 

char b_count; 

} buf[NR_BUFS]; 


/* para enlazar todos los bufs libres en cadena */ 
/* para enlazar los bufs libres en el otro sentido */ 
/* para enlazar bufs en cadenas de dispersión */ 

/* # de bloque de su dispositivo (secund) */ 

/* disp. princ I secund donde reside el bloque */ 

/* CLEAN o DIRTY */ 

/* núm de usuarios de este buffer */ 


/* Un bloque está libre si b_dev = NO_DEV. */ 

#defme NIL_BUF ((struct buf *) 0) /* indica ausencia de buffer */ 

/* Estas defs. permiten usar bp->b_data en vez de bp->b.b—data */ 

#define b_data b.b—data 

#defme b_dir b.b—dir 

#defme b_vl_ind b.b-vl_ind 20145 #defme b_v2_ind b.b-v2_ind 

#define b_vl_ino b.b-vl_ino 20147 #defíne b_v2_ino b.b-v2_ino 20148 #defme b_bitmap b.b—bitmap 20149 

EXTERN struct buf *buf_hash[NR_BUF_HASH] ;/* tabla de disp. de buffers */ 

EXTERN struct buf *ffont; /* apunta a bloque libre menos rec. usado */ 

EXTERN struct buf *rear;/* apunta a bloque libre más rec. usado */ 

EXTERN int bufs_in_use;/* # buffers en uso (no en lista libre)*/ 


/* Al liberarse un bloque, el tipo de uso se pasa a put_block(). */ 

#defme WRITE_IMMED 0100 /* bloque debe escribo en disco ahora */ 
#defíne ONE_SHOT 0200 /* 1 si bloque no se necesitará pronto */ 


#defme INODE BLOCK (0 + MAYBE WRITE IMMED) /* bloque nodos-i */ 
#defme DIRECTORY BLOCK (1 + MAYBE WRITE IMMED) /* bloque directorio */ 
#define INDIRECT BLOCK (2 + MAYBE WRITE IMMED) /* bloque apuntadores *’ 

#defme MAP BLOCK (3 + MAYBE WRITE IMMED) /* mapa de bits *’ 

#define ZUPER BLOCK (4 + WRITE IMMED + ONE SHOT) /* superbloque */ 

#defme FULL DATA BLOCK 5 /* datos, tot usado */ 

#defme PARTIAL DATA BLOCK 6 /* datos, pare usado*’ 


#defme HASH_MASK (NR_BUF_HASH -1) /* máscara p/dispersar núms bloque */ 
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20200 /* Tabla de dispositivos. Se indiza por núm de disp. principal. 

20201 * Vincula los núms de disp principal y las rutinas que los procesan. 

20202 */ 

20203 

20204 typedef PROTOTYPE (void (*dmap_t), (int task, message *m_ptr)); 

20205 

20206 extern struct dmap { 

20207 dmap_t dmap_open; 

20208 dmap_t dmap_rwj 

20209 dmap_t dmap_closej 

20210 int dmap_task; 

20211 } dmap[ ]; 

20212 


20300 


/* Tabla filp. Es un intermediario entre los descriptores de archivo y 


20301 * los nodos-i. Está libre una ranura si filp_count == 0. 

20302 */ 

20303 

20304 EXTERN struct filp { 

20305 mode_t filp_modej 

20306 int filp_flags; 

20307 int filp_count; 

20308 struct inode *filp_inoj 

20309 off_t filp_pos; 

20310 } filp[NR_FILPS]; 

20311 

20312 #defme FILPCLOSED 

20313 

20314 #defme NIL_FILP (struct filp *) 0 


/* bits RW, dicen cómo se abrió archivo */ 
/* banderas de open y fcntl */ 

/* cuántos descrip. arch. comparten ranura*/ 
/* apuntador al nodo-i */ 

/* posición en el archivo */ 


/* filp_mode: disp asociado cerrado */ 


/* indica ausencia de ranura filp */ 


src/fs/lock.h 


20400 /* Tabla de candados de archivo. Como la filp, apunta a la tabla de 

20401 * nodos-i, pero en este caso para poner candados asesores. 

20402 */ 


20403 EXTERN struct filejock { 

20404 short lockjype; 

20405 pid_t lock_pid; 

20406 struct inode *lock_inode; 

20407 off_t lock_first; 

20408 ofiftlock_last; 

20409 } file_lock[NR_LOCKS]; 


/* F RDLOCK o F WRLOCK; 0 = ranura libre */ 
/* pid del proceso q/tiene el candado */ 

/* apuntador al nodo-i asegurado */ 

/* distancia del 1er byte asegurado */ 

/* distancia del últ byte asegurado */ 
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20500 /* Tabla de nodos-i. Contiene nodos-i en uso. En algunos casos 

20501 * se abrieron con una llamada open() o creat(); en otros, el FS mismo 

20502 * necesita el nodo-i por una razón u otra, como buscar un nombre de ruta 

20503 * en un directorio. La primera parte del struct contiene campos que están 

20504 * en el discoj la segunda contiene campos que no lo están. La parte 

20505 * de nodos-i de disco también se declara en "type.h" como 

20506 * ’dl_inode' para los sistemas de archivo VI y como 'd2_inode' 

20507 * para los sistemas V2. 

20508 */ 

20509 

20510 EXTERN struct inode { 

20511 mode_t i_mode; 

20512 nlink_t i_nlinks; 

20513 uid_ti_uid; 

20514 gid t i gid; 

20515 ojfj i_size; 

20516 time_t i_atime; 

20517 time_t i_mtime; 

20518 time_t i_ctime; 

20519 zone_t i_zone[V2_NR_TZONES] 

20520 

20521 /* Las siguientes cosas no están presentes en el disco. */ 

20522 dev_t i_dev; /* dispositivo en el que está el nodo-i */ 

20523 ino_t i_num; /* núm nodo-i en su dispositivo (secund) */ 

20524 int i_count; /* # veces se usó nodo.ij 0 = ranura libre */ 

20525 int i_ndzones; /* # zonas directas (Vx_NR_DZONES) */ 

20526 int i_nindirs; /* # zonas indirec. por bloque de indirec. */ 

20527 struct super_block *i_sp; /* apunt a superbloque del disp del nodo-i */ 

20528 char i dirt; /* CLEAN o DIRTY */ 

20529 char i_pipe; /* igual a I_PIPE si es conducto */ 

20530 char i_mount; /* bit encendido si montado en archivo */ 

20531 char i seek; /* encend. por LSEEK, apago por READ/WRITE */ 

20532 char i_update; /* bits ATIME, CTIME y MTIME están aqui */ 

20533 } inode[NR_INODES]; 

20534 

20535 

20536 #defme NIL_INODE (struct inode *) 0 /* indica ausencia ranura nodo-i */ 

20537 

20538 /* Valores de campo. CLEAN y DIRTY se definen en "const.h" */ 

20539 #define NOPIPE 0 /* i_pipe = NOPIPE si nodo-i no es conducto */ 

20540 #define I_PIPE 1 /* i_pipe = I_PIPE si nodo-i es conducto */ 

20541#defineNO_MOUNT 0 /* i_mount = NO_MOUNT si no montado en arch */ 

20542 #define I_MOUNT 1 /* i_mount = I_MOUNT si montado en archivo */ 

20543 #define NO_SEEK 0 /* i_seek = NO_SEEK si últ op no fue SEEK */ 

20544 #define ISEEK 1 /* i_seek = I_SEEK si últ op fue SEEK */ 


/* tipo archivo, protección, etc. */ 

/* cuántos vínculos a este archivo */ 

/* id de usuario del dueño del archivo */ 

/* número de grupo */ 

/* tamaño del archivo actual en bytes */ 

/* tiempo de último acceso (sólo V2) */ 

/* última modif. de datos del archivo */ 

/* últ. modif. del nodo.i mismo (sólo V2)*/ 
/* núms zona p/directo, ind y doble ind */ 
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20600 /* E 

stos nombres son 

inónimos de las 

variables del mensaje de entrada. */ 

20601 #defm 

acc time 

m.m2 11 


20602 #define .addr 

m.ml i3 


20603 #defme 

buffer 

m.ml_pl 


20604 #defme 

child 

m.ml i2 


20605 #defm 

co mode 

m.ml il 


20606 #define 

eff grp id 

m.ml i3 


20607 #defm 

eff user id 

m.ml i3 


20608 #defme 

erki 

m.ml_pl 


20609 #defme 

fd 

m.ml il 


20610 #defme 

fd2 

m.ml i2 


20611 #defme 

ioflags 

m.ml i3 


20612 #defme 

group 

m.ml i3 


20613 #defmereal grp id 

m.ml i2 


20614 #defme 

ls fd 

m.m2 il 


20615 #defm 

mk mode 

m.ml i2 


20616 #defme 

mode 

m.m3 i2 


20617 #defme 

c mode 

m.ml i3 


20618 #defme 

c ñame 

m.ml_pl 


20619 #defme 

ñame 

m.m3_p 1 


20620 #defme 

namel 

m.ml_pl 


20621 #defme 

name2 

m.ml_p2 


20622 #defmename length 

m.m3 il 


20623 #defm 

namel length 

m.ml il 


20624 #defm 

name2 length 

m.ml i2 


20625 #defme 

nbytes 

m.ml i2 


20626 #defme 

offset 

m.m2_ll 


20627 #defme 

20628 #defme 

parent 

m.ml_i2 


20629 #defme 

pathname 

m.m3 cal 


20630 #defme 

pid 

m.ml i3 


20631 #defmepro 

m.ml il 


20632 #defm 

rd only 

m.ml i3 


20633 #defm 

real user id 

m.ml i2 


20634 #defm 

request 

m.ml i2 


20635 #defm 

sig 

m.ml_i2 


20636 #defme slotl 

m.ml il 


20637 #defm 

tp 

m.m2 11 


20638 #defineutime actime 

m.m2_ll 


20639 #defme 

utime modtime 

m.m2_12 


20640 #defm 

e utime file 

m.m2_pl 


20641 #defm 

e utime length 

m.m2 il 


20642 #defn 

íe whence 

m.m2_i2 



20643 

20644 /* Estos nombres son sinónimos de las variables del mensaje de salida. */ 

20645 #defme reply_type ml.m_type 

20646 #defme reply_l 1 ml.m2_ll 

20647 #defme reply_il ml.mljl 

20648 #defme reply_i2 ml.ml_i2 

20649 #define reply_tl ml.m4_ll 

20650 #define reply_t2 ml.m4_12 

20651 #defme reply_t3 ml.m4_13 

20652 #define reply_t4 ml.m4_14 

20653 #defme reply_t5 ml.m4_15 
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20700 /* Tabla de superbloques. El FS raíz y todos los FS montados tienen una entrada 

20701 * aquí. La entrada contiene info. sobre los tamaños de los mapas de bits y nodos-i. 

20702 * El campo s_ninodes da el núm de nodos-i disponibles para archivos y directorios, 

20703 * incl. el directorio raíz. El nodo-i 0 está en el disco pero no se usa. Por tanto, 

20704 * s_ninodes = 4 implica que se usarán 5 bits en el mapa de bits: el bit 0, 

20705 * que siempre es 1 y no se usa, y los bits 1-4 para archivos y directorios. 

20706 * La organización del disco es: 

20707 * 

20708 * Elemento 

20709 * bloque arranque 

20710* superbloque 

20711 * mapa de nodos- 

20712 * mapa de zonas 

20713 * nodos-i 

20714* no se usa 

20715 * zonas de datos 

20716 * 

20717 * Una ranura de superbloque está libre si s dev == NO DEV. 

20718*/ 

20719 

20720 

20721 EXTERN struct super_block { 

20722 ino_t s_ninodes; 

20723 zonel_t s_nzones; 

20724 short s_imap_blocks; 

20725 short s_zmap_blocks; 

20726 zonel_t s_firstdatazone; 

20727 short s_log_zone_size; 

20728 off_t s_max_size; 

20729 short s_magic; 

20730 short s_pad; 

20731 zone_t s_zones; 

20732 

20733 /* Lo siguiente sólo se usa si el 

20734 struct inode *s_isup; 

20735 struct inode *s_imount; 

20736 unsigned s_inodes_per_block; 

20737 dev_t s_dev; 

20738 int s_rd_onlY; 

20739 int s_native; 

20740 int s_version; 

20741 int s_ndzones; 

20742 int s_nindirs; 

20743 bit_t s_isearch; 

20744 bit_t s_zsearch; 

20745 } super_block[NR_SUPERS] 

20746 

20747 #defme NIL_SUPER (struct super_block *) 0 

20748 #define IMAP 0 /* operando en mapa-bits de nodos-i */ 

20749 #define ZMAP 1 /* operando en mapa-bits de zonas */ 


superbloque esta en memoria. */ 

/* nodo-i p/dir raíz de FS montado */ 

/* nodo-i en el que está montado */ 

/* precalculado a partir del núm mág */ 
/* ¿de quién es este superbloque? */ 

/* 1 si sist. arch. montado sólo lectura */ 
/* 1 si sist. arch. sin interc. bytes */ 

/* versión sist. arch. 0 = mágico mal */ 
/* núm. zonas directas en nodo-i */ 

/* # zonas indir. por bloque indir. */ 

/* los nodos-i bajo este # bit se usan */ 
/* zonas bajo este # bit se usan */ 


/* # nodos-i usables en disp. secundo */ 

/* tamaño total disp, incl mapas-bits, etc */ 
/* # bloques ocup por mapa-bits de nodos-i * 
/* # bloques ocup por mapa-bits de zonas */ 
/* número de primera zona de datos */ 

/* 10g2 de bloques/zona */ 

/* tam máx de archivo en este dispos. */ 

/* núm mágico p/reconocer superbloques */ 
/* evitar relleno dependiente del compilo */ 
/* # zonas (sustituye a s nzones en V2) */ 


# bloques 


s_imap_blocks 

szmapblocks 

(s_ninodes + ’nodos.i/bloque' -l)/'nodos-i/bloque 
lo necesario p/llenar la zona actual 

(s_zones -s_firstadatazone)« s_log_zone_size 






EL CÓDIGO FUENTE DE MINIX 

Archivo: src/fs/table.c 

803 

src/fs/table.h 

20800 

/* Este archivo contiene la 

i tabla que transforma los números 


20801 

* de llamadas al sistema t 

;n las rutinas que las ejecutan. 


20802 

*/ 



20803 




20804 

#defme TABLE 



20805 




20806 

#include "fs.h" 



20807 

#include <minix/callnr.h> 



20808 

#include <minix/com.h> 



20809 

#include "buf.h" 


20810 

#include "dev.h" 



20811 

#include "file.h" 



20812 

#include "fproc.h" 



20813 

#include "inode.h" 



20814 

#include "lock.h" 



20815 

#include "super.h" 



20816 




20817 

PUBLIC PROTOTYPE (int (*call vector[NCALLS]), (void)) = { 


20818 

no sys, / 

* 0 = no se usa */ 


20819 

do exit, / 

* 1 = exit */ 


20820 

do fork, / 

* 2 = fork */ 


20821 

do read, / 

* 3 = read */ 


20822 

do write, / 

* 4 = write */ 


20823 

do open, / 

* 5 = open */ 


20824 

do clase, / 

* 6 = Glose */ 


20825 

no sys, / 

* 7 = wait */ 


20826 

do creat, / 

* 8 = creat */ 


20827 

do link, / 

* 9 = link */ 


20828 

do unlink, / 

* 10 = unlink */ 


20829 

no sys, / 

*11= waitpid */ 


20830 

do chdir, / 

* 12 = chdir */ 


20831 

do time, / 

*13= time */ 


20832 

do mknod, / 

* 14 = mknod */ 


20833 

do chmod, / 

* 15 = chmod */ 


20834 

do chown, / 

* 16 = chown */ 


20835 

no sys, / 

* 17 = break */ 


20836 

do stat, / 

*18 = stat */ 


20837 

do lseek, / 

*19 = lseek */ 


20838 

no sys, / 

* 20 = getpid */ 


20839 

do mount, / 

*21= mount */ 


20840 

do umount, / 

* 22 = umount */ 


20841 

do set, / 

* 23 = setuid */ 


20842 

no sys, / 

* 24 = getuid */ 


20843 

do stime, / 

* 25 = stime */ 


20844 

no sys, / 

* 26 = ptrace */ 


20845 

no sys, / 

* 27 = alarm */ 


20846 

do fstat, / 

* 28 = fstat */ 


20847 

no sys, / 

* 29 = pause */ 


20848 

do_utime, / 

* 30 = utime */ 


20849 

no sys, / 

* 31 = (stty) */ 


20850 

no=sys, / 

* 32 = (gtty) */ 


20851 

do_access, / 

* 33 = access */ 


20852 

no_sys, / 

* 34 ~ (nice) */ 


20853 

no_sys, / 

* 35 = (ftime) */ 


20854 

do_sync, / 

* 36 = sync */ 
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20855 no_sys, /* 37 = kill */ 

20856 do_rename, /*38 = rename */ 

20857 do_mkdir, /*39 = mkdir */ 

20858 do_unlink, /*40 = rmdir */ 

20859 do_dup, /* 41 = dup */ 

20860 do_pipe, /* 42 = pipe */ 

20861 do_tiros, /* 43= times */ 

20862 no_sys, /*44 = (prof) */ 

20863 no_sys, /* 45= no se usa */ 

20864 do_set, /* 46 = setgid */ 

20865 no_sys, /* 47 = getgid */ 

20866 no_sys, /* 48 = (signal)*/ 

20867 no_sys, /* 49 = no se usa */ 

20868 no_sys, /* 50 = no se usa */ 

20869 no_sys, /*51=(acct) */ 

20870 no_sys, /*52 = (phys) */ 

20871 no_sys, /*53 = (lock) */ 

20872 do_ioctl, /* 54 = ioctl */ 

20873 do_fcntl, /* 55 = fcntl */ 

20874 no_sys, /*56 = (mpx) */ 

20875 no_sys, /* 57 = no se usa */ 

20876 no_sys, /* 58 = no se usa */ 

20877 doexec, /*59 = execve */ 

20878 do_umask, /* 60 = umask */ 

20879 do_chroot, /* 61 = chroot */ 

20880 do_setsid, /* 62 = setsid */ 

20881 no_sys, /* 63 = getpgrp */ 

20882 

20883 no_sys, /* 64 = KSIG: señales con origen en el kemel */ 

20884 do_unpause, /* 65 = UNPAUSE */ 

20885 no_sys, /* 66 = no se usa */ 

20886 do_revive, /* 67 = REVIVE */ 

20887 no_sys, /* 68 = TASK REPLY */ 

20888 no_sys, /* 69 = no se usa */ 

20889 no_sys, /* 70 = no se usa */ 

20890 no_sys, /* 71 = SIGACTION */ 

20891 no_sys, /* 72 = SIGSUSPEND */ 

20892 no_sys, /* 73 = SIGPENDING */ 

20893 no_sys, /* 74 = SIGPROCMASK */ 

20894 no_sys, /* 75 = SIGRETURN */ 

20895 no_sys, /* 76 = REBOOT */ 

20896 }; 

20897 

20898 

20899 /* Algunos dispositivos podrían estar o no en la siguiente tabla. */ 

20900#defme DT(enable, open, rw, Glose, task) \ 

20901 { (enable ? (open): no_dev), (enable ? (rw): no_dev), \ 

20902 (enable? (cióse): no_dev), (enable ? (task): 0) }, 

20903 

20904 /* El orden de las entradas aquí determina la correspondencia entre 

20905 * núms de disp. principal y tareas. La la. entrada (disp princ 0) no se usa. 

20906 * La siguiente es disp princ 1, etc. Los dispositivos por caracteres 

20907 * Y por bloques pueden entremezclarse al azar. Si se cambia el orden, 

20908 * los dispositivos en <include/minix/boot.h> deben cambiarse a los nuevos valores. 

20909 * Los núms de disp principal empleados en /dev NO son iguales a los usados 

20910 * en el kernel (definidos en <include/minix/com.h». Si /dev/mem 

20911 * se cambia de 1, deberá modificarse NULL MAJOR en 

20912 * <include/minix/com.h>. 

20913 */ 

20914PUBLIC struct dmap dmap[ ] = { 
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20915 /* ? Abrir Leer/Escribir Cerrar # Tarea Disp. Archivo 

20916 - -— - - - - - 

20917 DT(1, no_dev, ~o_dev, no_dev, 0) /*0 = noseusa */ 

20918 DT(1, dev_opcl, call_task, dev_opcl, MEM) /*l=/dev/mem */ 

20919 DT(1, dev_opcl, call_task, dev_opcl, FLOPPY) /*2 = /dev/fd0 */ 

20920 DT(ENABLE_WINI, 

20921 dev_opcl, call_task, dev_opcl, WINCHESTER)/* 3 =/dev/hd0 */ 

20922 DT(1, tty_open, call_task, dev_opcl, TTY) /* 4 =/dev/ttyOO */ 

20923 DT(1, ctty_open, call_ctty,ctty_close, TTY) /* 5 = /dev/tty */ 

20924 DT(1, dev_opcl, call_task, dev_opcl, PRINTER) /*6 = /dev/lp */ 

20925 

20926 #if (MACHINE = IBMPC) 

20927 DT(ENABLE_NETWORKING, 

20928 net_open, call_task, dev_opcl 

20929 DT(ENABLE_COROM, 

20930 dev_opcl, call_task, dev_opcl 

20931 DT(0,0, 0, 0, 

20932 DT(ENABLE_SCSI, 

20933 dev_opcl, call_task, dev_opcl 

20934 DT(0,0, 0, 0, 

20935 DT(0,0, 0, 0, 

20936 DT(ENABLE_AUOIO, 

20937 dev_opcl, call_task, dev_opcl 

20938 DT(ENABLE_AUOIO, 

20939 dev_opcl, call_task, dev_opcl 

20940 #endif /* IBM_PC */ 

20941 

20942 #if (MACHINE == ATARI) 

20943 DT(ENABLE_SCSI, 

20944 dev_opcl, call_task, dev_opcl, SCSI) /* 7 = /dev/hdscsiO */ 

20945 #endif 

20946 }; 

20947 

20948 PUBLIC int max major = sizeof(dmap)/sizeof(struct dmap); 



21000 /* El sistema de archivos mantiene un caché de buffers para reducir el número 

21001 * de accesos a disco necesarios. Cada vez que se lee o escribe en el disco, 

21002 * se verifica si el bloque está en el caché. Este archivo administra 

21003 * el caché. 

21004 * 

21005 * Los puntos de entrada a este archivo son: 

21006 * get_block: obtener del caché un bloque para leer o escribir 

21007 * put_block: devolver bloque antes solicitado con get_block 

21008 * alloc_zone: asignar nueva zona (p/aumentar longitud de un archivo) 

21009* freezone: liberar una zona (cuando se quita un archivo) 

21010 * rw_block: leer o escribir un bloque en el disco mismo 

21011 * invalídate: quitar todos los bloques de caché de algún dispositivo 

21012 */ 

21013 

21014 #include "fs.h" 

21015 #include <minix/com.h> 

21016 #include <minix/boot.h> 

21017 #include "buf.h" 

21018 #include "file.h" 

21019 #include "íproc.h" 


INET PROC NR)/* 7 = /dev/ip */ 

COROM) /* 8 = /dev/cdO */ 

0) /* 9 = no se usa */ 

SCSI) /*10 = /dev/sd0 */ 

0) /*11 =no se usa */ 

0) /*12 = no se usa */ 

AUOIO) /* 13 = /dev/audio */ 

MIXER) /* 14 = /dev/mixer */ 
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21020 #include "super.h" 

21021 

21022 FORWARD _PROTOTYPE( void rm lru, (struct buf *bp)); 

21023 

21024 /*===== = = = = = == == ===== = = = = === = = = == = ======= = = = = === 

21025 * get_block * 

21026 *=- == ================ = ■ ============================== = 

21027 PUBLIC struct buf *get_block(dev, block, only_search) 

21028 register dev_t dev; /* ¿en qué disp está el bloque? */ 

21029 register block_t block; /* ¿qué bloque se desea? */ 

21030 int only_search; /* si NO_READ, no leer; si no, normal */ 

21031 { 

21032 /* Ver si el bloque solicitado está en el caché. Si está, devolver 

21033 * apuntador a él. Si no, expulsar otro bloque y traerlo (a menos que 

21034 * ’only_search' =1). Todos los bloques del caché no en uso se enlazan 

21035 * en una cadena; ’front' apunta al menos recientemente usado, y ’rear', 

21036 * al más recient. usado. Si 'only_search' es 1, el bloque solicitado 

21037 * se sobreescribirá por completo, así que sólo es necesario ver si está 

21038 * en el caché; si no está, cualquier buffer libre sirve. No es necesario 

21039 * leer el bloque de disco. Si ’only_search' es PREFETCH, no hay que 

21040 * leer el bloque del disco, y el dispositivo no debe marcarse 

21041 * en el bloque; así, los invocadores pueden saber si el bloque 

21042 * devuelto es válido. 

21043 * Además de la cadena LRU, hay una de dispersión para enlazar bloques cuyos 

21044 * números terminan con la misma cadena de bits, para búsqueda rápida. 

21045 */ 

21046 

21047 int b; 

21048 register struct buf *bp, *prev_ptr; 

21049 

21050 /* Buscar (dev, block) en la cadena de dispersión. Do_read() puede 

21051 * usar get_block(NO_DEV ...) para obtener un bloque sin nombre 

21052 * que llenar con ceros si alguien quiere leer de un agujero en un archivo, 

21053 * en cuyo caso esta búsqueda se pasa por alto. 

21054 */ 

21055 if (dev != NO DEV) { 

21056 b = (int) block & HASHMASK; 

21057 bp = buf_hash[b]; 

21058 while (bp != NIL BUF) { 

21059 if (bp->b_blocknr = block && bp->b_dev = dev) { 

21060 /* Se encontró el bloque requerido. */ 

21061 if (bp->b_count = 0) rm_lru(bp); 

21062 bp->b_count++; /* registrar bloque en uso */ 

21063 retum(bp); 

21064 } else { 

21065 /* Este bloque no es el que buscábamos. */ 

21066 bp = bp->b_hash; /* pasar a sigo bloque de cadena disp. */ 

21067 } 

21068 } 

21069 } 

21070 

21071 /* Bloque deseado no está en cadena disponible. Tomar el más viejo ('front'). */ 

21072 if ((bp = front) ==NIL_BUF) panic("all buffers in use", NR BUFS); 

21073 rm_lru(bp); 

21074 

21075 /* Quitar el bloque recién tomado de su cadena de dispersión. */ 

21076 b = (int) bp->b_blocknr & HASH MASK; 

21077 prev_ptr = buf_hash[b]; 

21078 if (prev_ptr = bp) { 

21079 buf_hash[b] = bp->b_hash; 
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21080 

21081 

21082 

21083 

21084 

21085 

21086 

21087 

21088 

21089 

21090 

21091 

21092 

21093 

21094 

21095 

21096 

21097 

21098 

21099 

21100 
21101 
21102 

21103 

21104 

21105 

21106 

21107 

21108 

21109 

21110 
21111 


/* El bloque tomado no está al frente de su cadena de disp. *1 
while (prev_ptr->b_hash != NIL_BUF) 
if (prev_ptr.>b_hash = bp) { 

prev_ptr->b_hash = bp->b_hash; 1 * lo hallamos *1 

} else { 

prev_ptr = prev_ptr->b_hash; 1 * seguir buscando *1 

} 

} 

1 * Si el bloque tomado está sucio, limpiarlo escribiéndolo en disco. 

* Evitar histéresis desalojando los demás bloques sucios p/mismo dispositivo. 

*1 

if (bp->b_dev !=NO_DEV) { 

if (bp->b_dirt == DIRTV) flushall(bp->b_dev); 

} 

1 * Llenar paráms. del bloque y agregarlo a la cadena de disp. en su lugar. *1 
bp->b_dev = dev; 1 * llenar núm. dispositivo *1 

bp->b_blocknr = block; 1 * llenar número de bloque *1 

bp->b_count++; 1 * registrar bloque en uso *1 

b = (int) bp->b_blocknr & HASH MASK; 
bp->b_hash = buf_hash[b]; 

buf_hash[b] = bp; 1 * agregar a lista de dispersión *1 

1 * Obtener bloque solicitado a menos que sea búsqueda o preobtención. *1 
if (dev != NODEV) { 

if (only search = PREFETCH) bp->b_dev = NO_DEV; 


if (only search = NORMAL) rw_block(bp, READING); 


: return(bp); 
¡ } 


1 * devolver bloque recién adquirido *1 


21116 7*============================================================* 

21117* put_block * 

21118 *=============================================================*; 

21119 PUBLIC void put_block(bp, blockjype) 

21120 register struct buf *bp; 1 * apunto a bloque por liberar *7 

21121 int blockjype; 1 * INODEBLOCK, DIRECTORV BLOCK o lo 

21122 { 

21123 /* Devolver un bloque a la lista de disponibles. Dependiendo de 'blockjype', 

21124 * puede ponerse al frente o al final de la cadena LRU. Los bloques 

21125 * que se espera necesitar pronto (p.ej. bloques de datos parco llenos) 

21126 * van al finalj los que quizá no se necesitarán pronto otra vez 

21127 * (p.ej. bloques de datos llenos) van al frente. Los bloques cuya pérdida 

21128 * podría dañar la integridad del sist. de archivos (p.ej. bloques de nodos-i) 

21129 * se escriben de inmediato en disco si están sucios. 

21130 *1 

21131 

21132 if (bp — NIL_BUF) retum; 1 * es más fácil verif. aquí qlen invocador *1 

21133 

21134 bp->b_count—; 1 * ahora hay un uso menos *1 

21135 if (bp->b_count != 0) retumj 1 * bloque aún en uso *1 

21136 

21137 bufs Jn_use—; 1 * un buffer de bloque menos en uso *1 

21138 

21139 1* Devolver este bloque a la cadena LRU. Si el bit ONE_SHOT está encendido 
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21140 * en ’block_type', no es probable que el bloque se necesite pronto; 

21141 * se coloca al frente de la cadena LRU para que sea el primero que se tome 

21142 * cuando se necesite posteriormente un buffer libre. 

21143 */ 

21144 if (block_type & ONE_SHOT) { 

21145 /* El bloque quizá no se necesitará pronto. Ponerlo al frente de la cadena; 

21146 * será el próximo bloque expulsado del caché. 

21147 */ 

21148 bp->b_prev = NILBUF; 

21149 bp->b_next = front; 

21150 if (front = NIL BUF) 

21151 rear = bp; /* la cadena LRU estaba vacía */ 

21152 else 

21153 front->b_prev = bp; 

21154 front = bp; 

21155 } else { 

21156 /* El bloque quizá se necesitará pronto. Ponerlo al final de la cadena; 

21157 * tardará mucho en ser expulsado del caché. 

21158 */ 

21159 bp->b_prev = rear; 

21160 bp->b_next = NILBUF; 

71161 if (rear = NIL BUF) 

21162 front = bp; 

21163 else 

21164 rear->b_next = bp; 

21165 rear = bp; 

21166 } 

21167 

21168 /* Algunos bloques son tan importantes (nodos-i, de indirección) que deben 

21169 * escribirse en disco de inmediato para evitar arruinar el sistema 

21170 * de archivos en caso de una caída. 

21171 */ 

21172 if ((block type & WRITE IMMED) && bp->b_dirt=DIRTY && bp->b_dev 1 = NO_DEV) 

21173 rw_block(bp, WRITING); 

21174 } 

21177 /*===== ====== === ======= = ======= = ===== 

21178 * alloc_zone * 

21179 ♦============================== = =============== == ======= == 

21180 PUBLIC zone_t alloc_zone(dev, z) 

21181 dev_t dev; /* disp. donde se quería zona */ 

21182 zone_t z; /* tratar de asignar nva. zona cerca */ 

21183 { 

21184 /* Asignar nueva zona en el dispositivo indicado y devolver su número. */ 

21185 

21186 int major, minor; 

21187 bit_t b, bit; 

21188 struct super_block *sp; 

21189 

21190 /* La rutina alloc_bit() devuelve 1 para la zona más baja posible, 

21191 * que corresp. a sp->s_firstdatazone. Para convertir un valor 

21192 * entre el número de bit, ’b', empleado por alloc_bit() y el número 

21193 * de zona, ’z', almacenado en el nodo-i, use la fórmula: 

21194 * z = b + sp->s_firstdatazone -1 

21195 * Alloc_bit() nunca devuelve 0, que se usa para NO_BIT (fracaso). 

21196 */ 

21197 sp = get_super(dev); /* encontrar superbloque p/este disp. */ 

21198 

21199 /* Si z es 0, saltar parte inicial del mapa que se sabe está toda en uso. */ 
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21200 if (z = sp->s_firstdatazone) { 

21201 bit = sp->s_zsearch; 

21202 } else { 

21203 bit = (bit_t) z -(sp->s_firstdatazone -1); 

21204 } 

21205 b = alloc_bit(sp, 1MAP, bit); 

21206 if (b T= NO BIT) { 

21207 errcode = ENOSPC; 

21208 major = (int) (sp->s_dev » MAJOR) & BYTE; 

21209 minor = (int) (sp->s_dev » MINOR) & BYTE; 

21210 printf("No space on %sdevice %d/%d\n", 

21211 sp->s_dev == ROOT DEV ? "root' : major, minorjj 

21212 retum(N 0_ZONE); 

21213 } 

21214 if (z = sp->s_firstdatazone) sp->s_zsearch = b; /* p/sigte. vez */ 

21215 retum(sp->s_firstdatazone -1 + (zone_t) b); 

21216 } 

21219 /♦==== ======== = ==== == == = === == = = == = 

21220 * freezone 

21221 *== = == = ====== = ==== == == === = = = == = = ==== == == = = === 

21222 PUBLIC void free_zone(dev, numb) 

21223 dev_t dev; /* disp. donde está zona */ 

21224 zone_tnumb; /* zona por devolver */ 

21225 { 

21226 /* Devolver una zona. */ 

21227 

21228 register struct super_block * sp; 

21229 bit t bit; 

21230 

21231 /* Encontrar el superbloque apropiado y devolver bit. */ 

21232 sp = get_super(dev); 

21233 if (numb < sp->s_firstdatazone 11 numb >= sp->s_zones) retum; 

21234 bit = (bit_t) (numb -(sp->s_firstdatazone -1)); 

21235 free_bit(sp, ZMAP, bit); 

21236 if (bit < sp->s_zsearch) sp->s_zsearch = bit; 

21237 } 

21240 /*================= === ====================== == ====== 

21241 * rw_block 

21242 *============================== = ===================== == 

21243 PUBLIC void rw_block(bp, rw_flag) 

21244 register struct buf *bp; /* apuntador a buffer */ 

21245 int rw_flag; /* READING o WRITING */ 

21246 { 

21247 /* Leer o escribir un bloque de disco. Esta es la única rutina en la que se invoca 

21248 * realmente E/S de disco. Si hay error, se exhibe un mensaje aquí, pero el error 

21249 * no se informa al invocador. Si el error ocurrió mientras se purgaba un bloque 

21250 * del caché, no queda claro qué podría hacer el invocador en todo caso. 

21251 */ 

21252 

21253 int r, op; 

21254 offtpos; 

21255 dev_tdev; 

21256 

21257 if ( (dev = bp->b_dev) != NO_DEV) { 

21258 pos = (offt) bp->b_blocknr * BLOCKSIZE; 

21259 op = (rw_flag = READING ? DEV READ : DEV WRITE); 




*/ 
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21260 r = dev_io(op, FALSE, dev, pos, BLOCKSIZE, FS_PROC_NR, bp->b_data); 

21261 if (r 1= BLOCK SIZE) { 

21262 if (r >= 0) r = ENDOFFILE; 

21263 if (r 1 = ENDOFFILE) 

21264 printf("Unrecoverable disk error on device %d/%d, block %ld\n", 

21265 (dev»MAJOR)&BYTE, (dev»MINOR)&BYTE, bp->b_blocknr); 

21266 bp->b_dev = NO_DEV; /* invalidar bloque */ 

21267 

21268 /* Informar errores de lectura a las partes interesadas. */ 

21269 if (rw_flag ==■ READING) rdwt err = r; 

21270 } 

21271 } 

21272 

21273 bp->b_dirt = C EL AN; 

21274 } 

21277 /*===== = = === = = = = ====== = = = == == == = == = === == === = = == === = = ==== = = === 

21278 * invalídate * 

21279 * = = = = = ==== = = = = == = = = = = == === = = = = == = = = === == = = = = = = == = == = == = = = = = 

21280PUBLIC void invalidate(device) 

21281 dev_t device; /* disp. cuyos bloques se purgarán */ 

21282 { 

21283 /* Quitar del caché todos los bloques pertenecientes a algún dispositivo. */ 

21284 

21285 register struct buf *bp; 

21286 

21287 for (bp = &buf[0]; bp < &bUfINR_BUFS]; bp++) 

21288 if (bp->b_dev = device) bp->b_dev = NO_DEV; 

21289 } 

21292 /*==== ====== ===== == = = == = = = ===== = = === = = == === = 

21293 * flushall * 

21294 * ==== ==== == == ==== = ====== = == = ====== = === = === 

21295 PUBLIC void flushall(dev) 

21296dev_t dev; /* dispositivo p/desalojar */ 

21297 { 

21298/* Desalojar todos los bloques sucios p/un dispositivo. */ 

21299 

21300 register struct buf *bp; 

21301 static struct buf *dirtY[NR_BUFS]; /* static; no está en pila */ 

21302 intndirty; 

21303 

21304 for (bp = &buf[0], ndirty = 0; bp < &buf[NR_BUFS]; bp++) 

21305 if (bp->b_dirt = DIRTY && bp->b_dev = dev) dirty[ndirty++] = bp; 

21306 rw_scattered(dev, dirty, ndirty, WRITING); 

21307 } 


rw_scattered * 

PUBLIC void rw_scattered(dev, bufq, bufqsize, rw_flag) 

dev_t dev; /* núm disp principal/secundario */ 
struct buf **bufq; /* apuntador a matriz de buffers */ 

int bufqsize; /* número de buffers */ 
int rw_flag; /* READING o WRITING */ 


21310/ 

21311* 

21312* 

21313 

21314 

21315 

21316 

21317 

21318 

21319 


Leer o escribir datos dispersos de un dispositivo. */ 
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21320 

21321 

21322 

21323 

21324 

21325 

21326 

21327 

21328 

21329 

21330 

21331 

21332 

21333 

21334 

21335 

21336 

21337 

21338 

21339 

21340 

21341 

21342 

21343 

21344 

21345 

21346 

21347 

21348 

21349 

21350 

21351 

21352 

21353 

21354 

21355 

21356 

21357 

21358 

21359 

21360 

21361 

21362 

21363 

21364 

21365 

21366 

21367 

21368 

21369 

21370 

21371 

21372 

21373 

21374 

21375 

21376 

21377 

21378 

21379 


register int i; 

register struct iorequest_s *iop; 

static struct iorequest s iovec[NR_IOREQS]; 


/* Ordenar (shellsort) buffers por b_blocknr. */ 
gap= 1; 
do 

gap = 3 * gap + 1; 
while (gap <= bufqsize); 
while (gap 1= 1) { 
gap /= 3; 

for (j = gap; j < bufqsize; j++) { 
for(i=j-ga 


>= 0 && bufq[i] ->b_blocknr > bufq[i + gap] ->b_blocknr; 

i -= gap) { 
bp = bufq[i]; 
bufq[i] = bufq[i + gap]; 
bufq[i + gap] = bp; 


/* Preparar vector de E/S y efectuar E/S. El resultado de dev_io se desecha 

* porque todos los resultados se devuelven en el vector. Si dev_io fracasa 

* totalmente, el vector no cambia y los resultados se toman como errores. 

while (bufqsize > 0) { 

for (j = 0, iop = iovec; j < NRIOREQS && j < bufqsiZej j++, iop++) { 
bp = bufq[j]; 

iop->io_position = (offt) bp->b_blocknr * BLOCKSIZE; 
iop->io_buf = bp->b_data; 
iop->io_nbytes = BLOCKSIZE; 
iop->io_request = rw flag = WRITING ; 

DEV WRITE : DEV READ I OPTIONAL IO; 

} 

(void) dev_io(SCATTERED_IO, 0, dev, (offt) 0, j, FS_PROC_NR, 

(char *) iovec); 

/* Cosechar resultados. Dejar los de lectura pique rw_block() se queje. */ 
for (i = 0, iop = iovec; i < j; /++, iop++) { 
bp = bufq[i]; 

if (rw_flag = READING) { 
if (iop->io_nbytes = 0) 

bp->b_dev = dev; /* validar bloque */ 

put_block(bp, PARTIAL DATA BLOCK); 

} else { 

if (iop->io_nbytes != 0) { 

printf("Unrecoverable write error on device %d/%d, block %ld\n", 
(dev»MAJOR)&BYTE, (dev»MINOR)&BYTE, bp->b_blocknr); 
bp->b_dev = NO_DEV; /* invalidar bloque */ 

} 

bp->b_dirt = CLEAN; 

} 

} 

bufq+=j; 
bufqsize -= j; 
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21380 } 

21381 } 

21384 /*== = = === = = = = = = == = = = = === = == == = = = = = = ===== = === = == == === * 

21385 * rm_lru * 

21386 ♦ === == == = = == = = = ==== = =========== = == = = = ===== = ♦/ 

21387PRIVATE void rm_lru(bp) 

21388struct buf *bp; 

21389 { 

21390 /* Quitar un bloque de su cadena LRU. */ 

21391 

21392 struct buf *next_ptr, *prev_ptr; 

21393 

21394 bufs_in_use++; 

21395 next_ptr = bp->b_next; /* sucesor en cadena LRU *1 

21396 prev_ptr = bp->b_prev; /* predecesor en cadena LRU */ 

21397 if (prev_ptr != NILBUF) 

21398 prev_ptr->b_next = next_ptr; 

21399 else 

21400 front = next_ptr; /* este bloque estaba al frente */ 

21401 

21402 if (next_ptr != NIL BUF) 

21403 next_ptr->b_prev = prev_ptr; 

21404 else 

21405 rear = prev_ptr; /* este bloque estaba al final */ 

21406 } 


src/fs/inode.c 


21500 

21501 

21502 

21503 

21504 

21505 

21506 

21507 

21508 

21509 

21510 

21511 

21512 

21513 

21514 

21515 

21516 

21517 

21518 

21519 

21520 

21521 

21522 

21523 

21524 


/* Este archivo administra la tabla de nodos-i. Hay procedimientos 

* para asignar, quitar, adquirir, borrar y liberar nodos-i, Y leerlos 

* de y escribirlos en disco. 


* Los puntos de entrada a este archivo son 

* get_inode: buscar nodo-i dado en tabla; si no está, leerlo 

* put_inode: indicar que un nodo-i ya no se necesita en memoria 

* alloc_inode: asignar un nuevo nodo-i no utilizado 

* wipe_inode: borrar algo campos de un nodo-i recién asignado 

* free_inode: marcar nodo-i como disponible para un nuevo archivO 

* update_times: actualizar atime, ctime y mtime 

* rw_inode: leer bloque disco y extraer nodo-i, o escribirlo 

* old_icopy: copiar a/de struct inode en núcleo y nodo-i disco (vi .x) 

* new_icopy: copiar a/de struct inode en núcleo y nodo-i disco (v2.x) 

* dup_inode: indicar que alguien más usa la entrada tabla nodos-i 


#include "fs.h" 

#include <minix/boot.h> 
#include "buf.h" 

#include "file.h" 

#include "fproc.h" 
#include "inode.h" 
#include "super.h" 
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21525 FORWARD _PROTOTYPE( void oldicopy, (struct inode *rip, dl inode *dip, 

21526 int direction, int norm)); 

21527 FORWARD _PROTOTYPE( void newicopy, (struct inode *rip, d2_inode *dip, 

21528 int direction, int norm)); 

21529 

21530 

21531 /* == ~================= == : ^ =========== = ========= == ====== 

21532 * get_inode 

21533 *=== .^. ================ ^ ===== = ======== == ============== 

21534 PUBLIC struct inode *get_inOde(dev, numb) 

21535 dev_t dev; /* disp. donde reside nodo-i */ 

21536 int numb; /* # nodo-i (ANSI: nunca unshort) */ 

21537 { 

21538 /* Encontrar una ranura en la tabla de nodos-i, cargar el nodo-i especificado en ella 

21539 * Y devolver un apuntador a la ranura. Si 'dev' = NO_DEV, s610 devolver una ranura libre. 

21540 */ 

21541 

21542 register struct inode *rip, *xp; 

21543 

21544 /* Buscar tanto (dev, numb) como 1 ranura libre en tabla de nodos-i. */ 

21545 xp = NILINODE; 

21546 for (rip = &inode[0] j rip < &inode[NR_INODESlj rip++) { 

21547 if (rip->i_count > 0) { /* s610 buscar en ranuras usadas */ 

21548 if (rip->i_dev = dev && rip->i_num = numb) { 

21549 /* Este es el nodo que buscamos. */ 

21550 rip->i_count++; 

21551 retum(rip); /* hallamos (dev, numb) */ 

21552 } 

21553 } else { 

21554 xp = rip; /* recordar esta rano libre después */ 

21555 } 

21556 } 

21557 

21558 /* Nodo-i deseado no está en uso. ¿Encontramos una ranura libre? */ 

21559 if (xp = NIL INODE) { /* tabla nodos-i totalmente llena */ 

21560 errcode = ENFILE; 

21561 retum(NIL_INODE); 

21562 } 

21563 

21564 /* Encontramos ranura de nodo-i libre. Cargar nodo-i en ella. */ 

21565 xp->i_dev = dev; 

21566 xp->i_num = numb; 

21567 xp->i_count = 1; 

21568 if (dev 1= NO DEV) rw_inode(xp, READING); /* obtener nodo de disco */ 

21569 xp->i_update = 0; /* todos los tiempos inic. actualizados */ 

21570 

21571 retum(xp); 

21572 } 

21575 /♦= ======= == =============== = === = === = 

21576 * put_inode 

21577 *============== = === = ==== = = = ==== = == = ======= == = 

21578 PUBLIC void put_inode(rip) 

21579 register struct inode *rip; /* apunto a nodo-i por liberar */ 

21580 { 

21581 /* El invocador ya no usa este nodo-i. Si nadie más lo usa 

21582 * escribirlo en disco de inmediato. Si no tiene vínculos, truncarlo 

21583 * Y devolverlo a la reserva de nodos-i disponibles. 

21584 */ 
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21585 

21586 if (rip = NIL_INODE) retum; /* más fácil verif. aquí q/en invocador */ 

21587 if (—rip->i_count = 0) { /* i_count = 0 implica q/nadie lo usa */ 

21588 if ((rip->i_nlinks & BYTE) = 0) { 

21589 /* i_nlinks = 0 implica liberar el nodo-i. */ 

21590 truncate(rip); /* devolver todos los bloques de disco */ 

21591 rip->i_mode = I_NOT_ALLOC; /* borrar campo ITYPE */ 

21592 rip->i_dirt = DIRTY; 

21593 ffee_inode(rip->i_dev, rip->i_num); 

21594 } else { 

21595 if (rip->i_pipe = I_PIPE) truncate(rip); 

21596 } 

21597 rip->i_pipe = NO_PIPE; /* siempre debe borrarse */ 

21598 if (rip->i_dirt = DIRTY) rw_inode(rip, WRITING); 

21599 } 

21600 } 

21602 /*== = = = == = = = = = = == == = = = = = == = = = = === = == == = = = = = = == = ==== = = = = = === = 

21603 * alloc_inode * 

21604 * = ========= = = == ================ = === = ====== = ===== = == = = == 

21605 PUBLIC struct inode *alloc_inode(dev, bits) 

21606 dev_t dev; /* disp. en el cual asignar nodo-i */ 

21607 mode_tbits; /* modo del nodo-i */ 

21608 { 

21609 /* Asignar nodo-i libre en 'dev' y devolver apuntador a él. */ 

21610 

21611 register struct inode *ripj 

21612 register struct super_block * sp; 

21613 int maj ar, minar, inumb; 

21614 bitjbj 

21615 

21616 sp = get_super(dev); /* obtener apuntador a superbloque */ 

21617 if (sp->s_rd_only) { /* imposible asignar nodo en disp. sólo lectura. */ 

21618 errcode = EROFS; 

21619 return(NIL_INODE); 

21620 } 

21621 

21622 /* Adquirir un nodo-i del mapa de bits. */ 

21623 b = alloc_bit(sp, IMAP, sp->s_isearch); 

21624 if (b = NOBIT) { 

21625 errcode = ENFILE; 

21626 maj ar = (int) (sp->s_dev » MAJOR) & BYTE; 

21627 minar = (int) (sp->s_dev » MINOR) & BYTE; 

21628 printf("Out of i-nodes on %sdevice %d/%d\n", 

21629 sp->s_dev == ROOT DEV ? "root " : majar, minor); 

21630 retum(NIL_INODE); 

21631 } 

21632 sp->s_isearch = b; /* sigte vez comenzar aquí */ 

21633 inumb = (int) bj /* no pasar unshort como parám. */ 

21634 

21635 /* Tratar de adquirir una ranura de la tabla de nodos-i. */ 

21636 if ((rip = get inode (NO_DEV , inumb» == NIL INODE) { 

21637 /* No hay ranuras disponibles. Liberar el nodo recién asignado. */ 

21638 free_bit(sp, IMAP, b); 

21639 } else { 

21640 /* Ranura disponible. Colocar en ella el nodo-i recién asignado. */ 

21641 rip->i_mode = bitsj /* establecer bits RWX */ 

21642 rip->i_nlinks = (nlink_t) 0; /* inic. sin vínculos */ 

21643 rip->i_uid = fp->fp_effuid; /* uid del arch es el del dueño */ 

21644 rip->i_gid = fp->fp_effgid; /* ídem id de grupo */ 
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21645 rip->i_dev = dev; /* marcar en cuál disp está */ 

21646 rip->i_ndzones = sp->s_ndzones; /* núm zonas directas */ 

21647 rip->i_nindirs = sp->s_nindirs; /* núm zonas indirectas/bloque*/ 

21648 rip->i_sp = sp; /* apuntador a superbloque */ 

21649 

21650 /* Los campos aún no borrados se borran en Wipe_inOde(). 

21651 *Se pusieron ahí porque truncate() necesita borrar los mismos 

21652 * campos si el archivo está abierto mientras se trunca. Se ahorra 

21653 * espacio si no se repite el código dos veces. 

21654 */ 

21655 wipe_inode(rip); 

21656 } 

21657 

21658 retum(rip); 

21659 } 

21661 /♦ = : == ======== = ==== == === = =========== = ================: 

21662 * wipe_inode * 

21663 *= =- ■ . ==^====^= ^^ ===== ^--.^ ============================= 

21664 PUBLIC void wipe inode(rip) 

21665 register struct inode *rip' /* el nodo-i por borrar */ 

21666 { 

21667 /* Borrar unos campos del nodo-i. Esta función se invoca desde alloc inode() 

21668 * cuando se va a asignar un nuevo nodo-i, y de truncate() cuando se-va 

21669 * a truncar un nodo-i existente. 

21670 */ 

21671 

21672 register int i; 

21673 

21674 rip->i_size = 0; 

21675 rip->i_update = ATIME I CTIME IMTIME; /* actualizar tiempos después */ 

21676 rip->i_dirt = DIRTY; 

21677 for (i = 0; i < V2_NR_T10NES; i++) rip->i_zone[i] = N0_10NE; 

21678 } 

21681 /*========= = ========================================= == 

21682 * free inode * 

21683 *=== ^ ■ — i^=;====i===================== == : 

21684 PUBLIC void free inode(dev, inumb) 

21685 dev_t dev; -/* en cuál dispositivo está el nodo-i */ 

21686 ino_t inumb; /* núm del nodo-i por liberar */ 

21687 { 

21688 /* Devolver un nodo-i a la reserva de nodos no asignados. */ 

21689 

21690 register struct super_block *sp; 

21691 bit_t b; 

21692 

21693 /* Encontrar el superbloque apropiado. */ 

21694 sp = get_super(dev); 

21695 if (inumb <=011 inumb > sP->s_ninodes) retum; 

21696 b = inumb; 

21697 free_bit(sp, IMAP, b); 

21698 if (b < sP->s_isearCh) sP->s_isearch = b; 

21699 } 

21701 /*===== ====== == == = == == ===== ==== ====== 

21702 * update_times * 

21703 *========================-=========================== 

21704 PUBLIC void update times(rip) 
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21705 register struct inode *rip; /* apunt a nodo-i por leer/escribir */ 

21706 { 

21707 /* El estándar exige que varias llamadas al sist. actualicen atime, ctime 

21708 * o mtime. Ya que para ello hay que enviar un mensaje a la tarea del reloj, 

21709 * lo cual es caro, los tiempos se marcan para actualización encendiendo bits 

21710 * en i_update. Al terminar una stat, fstat o sync, o al liberarse un nodo-i, 

21711 * se puede invocar update_times() para asentar realmente los tiempos. 

21712 */ 

21713 

21714 time_t cur_time; 

21715 struct super_block * sp; 

21716 

21717 sp = rip->i_sp; /* obtener apunt a superbloque. */ 

21718 if (sp->s_rd_only) retum; /* no actualizo en FS sólo de lectura */ 

21719 

21720 cur_time = clock_time(); 

21721 if (rip->i_update & ATIME) rip->i_atime = cur_time; 

21722 if (rip->i_update & CTIME) rip->i_ctime = cur_time; 

21723 if (rip->i_update & MTIME) rip->i_mtime = cur_time; 

21724 rip->i_update = 0; /* ya están actualizados */ 

21725 } 

21728 /* = = = = == = == = = == = = = = === = = = == === = = = = = == = = = = = = == = = = = = = ="= ==== 

21729 * rw_inode * 

21730 *= = = == ===== = ============== = = = == = = = = = = == == = = = = = = = = = = == = = = = = = == 

21731 PUBLIC void rw_inode(rip, rw_flag) 

21732 register struct inode *rip; /* apunto a nodo-i por leer/escribir */ 

21733 int rw_flag; /* READING o WRITING */ 

21734 { 

21735 /* Una entrada de tabla nodos-i debe copiarse en o de disco. */ 

21736 

21737 register struct buf *bp; 

21738 register struct super_block *sp; 

21739 dl_inode *dip; 

21740 d2_inode *dip2; 

21741 block_t b, offset; 

21742 

21743 /* Obtener bloque donde reside el nodo-i. */ 

21744 sp = get_super(rip->i_dev); /* obt. apunto a superbloque */ 

21745 rip->i_sp = sp; /* nodo-i debe contener apunt a superbl */ 

21746 offset = sp->s_imap_blocks + sp->s_zmap_blocks + 2; 

21747 b = (block_t) (rip->i_num -1 )/sp->s_inodes_per_block + offset; 

21748 bp = get_block(rip->i_dev, b, NORMAL); 

21749 dip = bp->b_vl_ino + (rip->i_num 1) % Vl_INODES_PER_BLOCK; 

21750 dip2 = bp->b_v2_ino + (rip->i_num -1) % V2_INODES_PER_BLOCK; 

21751 

21752 /* Efectuar lectura o escritura. */ 

21753 if(rw_flag = WRITING) { 

21754 if (rip->i_update) update_times(rip); /* hay que acto tiempos */ 

21755 if (sp->s_rd_only = FALSE) bp->b_dirt = DIRTY; 

21756 } 

21757 

21758 /* Copiar el nodo-i del bloque de disco a la tabla en núcleo o viceversa. 

21759 * Si el cuarto parám es FALSE, los bytes se intercambian. 

21760 */ 

21761 if (sp->s_version == V1) 

21762 old_icopy(rip, dip, rw_flag, sp->s_native); 

21763 else 

21764 new_icopy(rip, dip2, rw_flag, sp->s_native); 
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21765 

21766 

21767 

21768 

21771 

21772 

21773 

21774 

21775 

21776 

21777 

21778 

21779 

21780 

21781 

21782 

21783 

21784 

21785 

21786 

21787 

21788 

21789 

21790 

21791 

21792 

21793 

21794 

21795 

21796 

21797 

21798 

21799 

21800 
21801 
21802 

21803 

21804 

21805 

21806 

21807 

21808 

21809 

21810 
21811 
21812 

21813 

21814 

21815 
21818 

21819 

21820 
21821 
21822 

21823 

21824 


put_block(bp, INODEBLOCK); 
rip- > i_dirt = CLEAN; 

} 


old_icopy 


PRIVATE void oíd icopy(rip, dip, direction, norm) 

register struct inode *rip; /* apunt a struct inode en núcleo */ 

register dl_inode *dip; /* apunt a struct inode dl_inode */ 

int direction; /* READING (de disco) o WRITING (en disco) */ 

int norm; /* TRUE = no intercamb. bytes; FALSE = sí */ 


{ 

/* El disco IBM Vl.x, el disco 68000 Vl.x y el disco V2 (mismo para IBM 

* Y 68000) tienen diferentes organizo de nodos-i. Al leerse o escribirse 

* un nodo esta rutina hace las conversiones para que la info de la tabla de nodos-i 

* sea independiente de la estructura del disco del que provino el nodo-i. 

* La rutina old_icopy copia a y de discos VI. 


if (direction = READING) { 

/* Copiar nodo-i Vl.x en tabla en núcleo, interc. bytes si es preciso. */ 

rip->i_mode = conv2(norm, (int) diP->dl_mOde); 

rip->i_uid = conv2(norm, (int) dip->dl_uid); 
rip->i_size = COnv4(norm, dip->dl_Size); 

rip->i_mtime = COnv4(norm, dip->dl_mtime); 

rip->i_atime= rj-p->i_mtime; 
rip->i_ctime = rip->i_mtime; 

rip->i_nlinks = (nlink_t) dip->dl_nlinkS; 
rip- > i_gid = (gid_t) dip->dl_gid; 

rip->i_ndzones = 

rip->i_nindirs = VIJNDIRECTS; 
for (i = 0; i < VINRTIONES; i++) 

rip->i_zone[i] = conv2(norm, (int) dip->dl_zone[i])j 
} else { 

/* Se copia nodo-i Vl.x a disco de la tabla en núcleo. */ 
dip->dl_mode = conv2(norm, (int) rip->i_mode); 
dip->dl_uid = conv2(norm, (int) rip->i_uid )j 

dip->dl_size = cOnv4(norm, rip->i_size)j 

dip->dl_mtime = COnv4(norm, rip->i_mtime); 

dip->dl_nlinks = (nlink_t) rip->i_nlinks; 
dip->dl_gid = (gid_t) rip->i_gid; 
for (i = 0; i < VI NR TIONES; i++) 

dip->dl_zone[i] = conv2inorm, (int) rip->i_zone[i]); 

} 

} 


newicopy 


PRIVATE void new_icopy(rip, dip, direction, norm) 
register struct inode *ripj /* apunt a struct inode en núcleo */ 
register d2_inode *dip; /* apunt a struct d2_inode */ 
int direction; /* READING (de disco) o WRITING (en disco) */ 


/* 1 char */ 

/* 1 char */ 

V1 NRDIONE S; 


/* 1 char */ 
/* 1 char */ 
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21825 int norm; /* TRUE = no intercamb. bytes; FALSE = sí */ 

21826 

21827 { 

21828 /* Mismo que old_icopy, pero a/de disco con organizo V2. */ 

21829 

21830 int i;. 

21831 

21832 if (direction = READING) { 

21833 /* Copiar nodo-i V2.x en tabla en núcleo, interc. bytes si es preciso. */ 

21834 rip->i_mode = conv2(nOrm,dip->d2_mode); 

21835 rip->i_uid = conv2(nOrm,dip->d2_uid); 

21836 rip->i_nlinks = conv2(norm, (int) dip->d2_nlinks); 

21837 rip->i_gid = conv2(norm, (int) dip->d2_gid ); 

21838 rip->i_size = conv4(nOrm,dip->d2_size); 

21839 rip->i_atime = conv4(norm,dip->d2_atime); 

21840 rip->i_ctime = conv4(nOrm,dip->d2_ctime); 

21841 rip->i_mtime = conv4(nOrm,dip->d2_mtime); 

21842 rip->i_ndzones = V2NRD10NES; 

21843 rip->i_nindirs = V2_INDIRECTS; 

21844 for (i = 0; i < V2_NR_T10NES; i++) 

21845 rip->i_zone[i] = conv4(norm, (long) dip->d2_zone[i]); 

21846 } else { 

21847 /* Se copia nodo-i V2.x a disco de la tabla en núcleo. */ 

21848 dip->d2_mode = conv2(nOrm,rip->i_mode); 

21849 dip->d2_uid = conv2(nOrm,rip->i_uid); 

21850 dip->d2_nlinks = conv2(norm,rip->i_nlinks); 

21851 dip->d2_gid = conv2(norm,rip->i_gid); 

21852 dip->d2_size = conv4(norm,rip->i_size); 

21853 dip->d2_atime = conv4(nOrm,rip->i_atime); 

21854 dip->d2 ctime = conv4(norm,rip->i ctime); 

21855 dip->d2=mtime = conv4(nOrm,rip->i=mtime); 

21856 for (i = 0; i < V2_NR_T10NESj i++) 

21857 dip->d2_zone[i] = conv4(norm, (long) rip->i_zone[i]); 

21858 } 

21859 } 

21862 /*= = = = = == = == = = === = = == = = = = = === = == = == = = = = = == = == = = = = = = = === 

21863 * dup_inode * 

21864 *=========== = === = ==== = = = ===== ====== = = === == = = = = = == = = = = === === === = === 

21865 PUBLIC void dup_inode(ip) 

21866 struct inode *ip; /* El nodo-i por duplicar. */ 

21867 { 

21868 /* Esta rutina es una forma simplificada de get_inode() para 

21869 * el caso en que ya se conoce el apuntador a nodo-i. 

21870 */ 

21871 

21872 ip->i_count++; 

21873 } 
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21900 /* Este archivo administra la tabla de superbloques y las estruc. 

21901 * de datos relacionadas: los mapas de bits que indican cuáles zonas 

21902 * Y nadas están asignados/libres. Cuando se necesita un nuevo nodo-i 

21903 * o zona, se busca una entrada libre en el mapa de bits apropiado. 

21904 * 

21905 * Los puntos de entrada a este archivo son 

21906 * alloc_bit: alguien quiere asignar 1 zona o nodo-i; hallarlo 

21907 * free_bit: indicar que 1 zona o nodo-i está disponible p/asig. 

21908 * get_super: buscar un dispositivo en tabla’superblock' 

21909 * mounted: indica si nodo arch está en sist arch montado (o ROOT) 

21910 * read_super: leer un superbloque 

21911 */ 

21912 

21913 #include "fs.h" 

21914 #include <string.h> 

21915 #include <minix/boot.h> 

21916 #include "buf.h" 

21917 #include "inode.h" 

21918 #include " super.h" 

21919 

21920 #defme BITCHUNKBITS (usizeof(bitchunk_t) * CHAR BIT) 

21921 #defme BITS PER BLOCK (BITMAPCHUNKS * BITCHUNK BITS) 

21922 

21923 /*==================================================== = === == * 

21924 * alloc_bit * 

21925 *===—=-== ■= = —== ===== ■ ■ ■ ====== = ===== = =================== == */ 

21926 PUBLIC bit t alloc_bit(sp, map, origin) 

21927 stmct super_block *sp; /* sist arch del cual asignar */ 

21928 int map; /* IMAP (mapa nadas) o ZMAP (zonas) */ 

21929 bit_t origin; /*# bit donde iniciar búsqueda */ 

21930 { 

21931 /* Asignar un bit del mapa de bits y devolver su número. */ 

21932 

21933 block_t start_block; /* primer bloque de bits */ 

21934 bit_t map_bits; /* ¿cuántos bits en el mapa? */ 

21935 unsigned bit_blocks; /* ¿cuántos bloques en el mapa? */ 

21936 unsigned block, word, bcount, wcount; 

21937 struct buf *bp; 

21938 bitchunk_t *wptr, *wlim, kj 

21939 bit t i, b; 

21940 

21941 if (sp->s_rd_only) 

21942 panic("can't allocate bit on read-only filesys.", NO_NUM); 

21943 

21944 if (map = IMAP) { 

21945 start_block = SUPERBLOCK + 1; 

21946 map_bits = sp->s_ninodes + lj 

21947 bit_blocks = sp->s_imap_blocksj 

21948 } else { 

21949 startblock = SUPERBLOCK + 1 + sp->s_imap_blocks; 

21950 map_bits = sp->s_zones -(sp->s_fírstdatazone -1); 

21951 bit_blocks = sp->s_zmap_blocks; 

21952 } 

21953 

21954 /* Averiguar dónde iniciar búsqueda de bit (depende de 'origin'). */ 





820 


Archivo: 


src/fs/super.c EL CÓDIGO FUENTE DE MINIX 

21955 if (origin >= map_bitS) origin = 0; /* para robustez */ 

21956 

21957 /* Localizar el punto de inicio. */ 

21958 block = origin / BITS_PER_BLOCK; 

21959 word = (origin % BITS_PER_BLOCK) / BITCHUNKBITS; 

21960 

21961 /* Iterar con todos los bloques + 1, porque comenzamos en medio. */ 

21962 bcount = bit_blocks + 1; 

21963 do { 

21964 bp = get_block(sp->s_dev, start_block + block, NORMAL); 

21965 wlim = &bP->b_bitmap[BITMAP_CHUNKS]; 

21966 

21967 /* Iterar con las palabras del bloque. */ 

21968 for (wptr = &bp->b_bitmap[word]; wptr < wlim; wptr++) { 

21969 

21970 /* ¿Contiene esta palabra un bit libre? */ 

21971 if (*■wptr = (bitchunk_t) -0) continué; 

21972 

21973 /* Encontrar Y asignar el bit libre. */ 

21974 k = conv2(Sp->s_native, (int) *wptr); 

21975 for (i = 0; (k & (1 « i» 1= 0; ++i) {} 

21976 

21977 /* Núm de bit desde el principio del mapa de bits. */ 

21978 b = «bit_t) block * BITS_PER_BLOCK) 

21979 + (wptr -&bp->b_bitmap[0]) * BITCHUNK BITS 

21980 + i; 

21981 

21982 /* No asignar bits más allá del final del mapa. */ 

21983 if (b >= map bits) break; 

21984 

21985 /* Asignar Y devolver número de bit. */ 

21986 k 1— 1«i; 

21987 *wptr = conv2(sp->s_native, (int) k)j 

21988 bp->b_dirt = DIRTY; 

21989 put_block(bp, MAPBLOCK); 

21990 retum(b); 

21991 } 

21992 put_block(bp, MAPBLOCK); 

21993 if (-H-block >= bit_blockS) block = 0; /* últ. bloque, ir al inicio */ 

21994 word = 0; 

21995 } while (—bcount > 0); 

21996 retum(NO_BIT); /* no pudo asignarse un bit */ 

21997 } 

22000 /*==== — =============================== ===== ===== == ======== ==== = 

22001 * free_bit * 

22002 *========= = = .- ■ ■ ■ . ==== == ============================= == 

22003 PUBLIC void free_bit(sp, map, bit retumed) 

22004 struct super_block *sp; /* sist arch sobre el cual operar */ 

22005 int map; /* IMAP (mapa nodos) o ZMAP (zonas) */ 

22006 bit_t bit_retumed; /* # bit que insertar en el mapa */ 

22007 { 

22008 /* Regresar una zona o nodo-i apagando su bit en el mapa. */ 

22009 

22010 unsigned block, word, bit; 

22011 struct buf *bp; 

22012 bitchunk_t k, mask; 

22013 block_t start_blOck; 

22014 
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22015 

22016 

22017 

22018 

22019 

22020 
22021 
22022 

22023 

22024 

22025 

22026 

22027 

22028 

22029 

22030 

22031 

22032 

22033 

22034 

22035 

22036 

22037 

22038 

22039 

22040 

22041 
22044 


22045 * get_super * 

22046*==== = == = ===== = = == ==-=== = == = = = == === = == = = ==== = = = === == = == ===== = 

=*/ 

22047 PUBLIC struct super_block *get_super(dev) 

22048 dev_t dev; /* núm disp cuyo superbloque se busca */ 

22049 { 

22050 /* Buscar este dispositivo en tabla de superbloques. Debe estar ahí. */ 

22051 

22052 register struct super_block *sp; 

22053 

22054 for (sp = &super_block[0]; sp < &super_block[NR_SUPERS]; sp++) 

22055 if (sp->s_dev = dev) retum(sp); 

22056 

22057 /* Falló la búsqueda. Algo anda mal. */ 

22058 panic("can't fmd superblock for device fin decimal)", finí) dev); 

22059 

22060 retum(NIL_SUPER); /* p/mantener tranquilos al compilador y lint */ 

22061 } 

22064 


22065 * mounted 

22066*= = == === == == = = = == == = = = = = === = = ==== = = = = = = = = === = == = 

=*/ 

22067 PUBLIC int mounted(rip) 

22068 register struct inode *rip; /* apuntador a nodo-i */ 

22069 { 

22070 /* Informar si el nodo-i dado está en un sist arch montado (o ROOT). */ 

22071 

22072 register struct super_block *sp; 

22073 register dev_t dev; 

22074 


if (sp->s_rd_only) 

panic("can't free bit on read-only filesys.", NO_NUM); 

if (map = IMAP) { 

startblock = SUPERBLOCK + 1; 

} else { 

startblock = SUPERBLOCK + 1 + sp->s_imap_blocks; 

} 

block = bitretumed / BITS_PER_BLOCK; 

word = (bit retumed % BITS_PER_BLOCK) / BITCHUNKBITS; 

bit = bit_retumed % BITCHUNK BITS; 

mask = 1 « bit; 

bp = get_block(sp->s_dev, start_block + block, NORMAL); 

k = conv2(sp->s_native, finí) bp->b_bitmap[word]); 
if (!(k & mask» { 

panic(map == IMAP ? "tried to free unused inode" : 

"tried to free unused block", NO_NUM); 

} 

k &= 'mask; 

bp->b_bitmap[word] = conv2(sp->s_native, (int) k); 
b->b_dirt = DIRTY; 

put_block(bp, MAP BLOCK); 

} 
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22075 dev = (dev t) rip->i_zone[0]; 

22076 if (dev == ROOT_DEV) retum(TRUE); /* nodo está en sist arch raíz */ 

22077 

22078 for (sp = &super_block[01j sp < &super_block[NR_SUPERS] j sp++) 

22079 if (sp->s_dev == dev) retum(TRUE); 

22080 

22081 retum(FALSE); 

22082 } 

22085 

22086 * read_super * 

22087 


22088 PUBLIC int read_super(sp) 

22089 register struct super_block *sp; /* apuntador a superbloque */ 

22090 { 

22091 /* Leer un superbloque. */ 

22092 

22093 register struct buf *bp; 

22094 dev_t dev; 

22095 int magic; 

22096 int versión, native; 

22097 

22098 dev = sp->s_dev; /* guardar disp (copia lo sobreescribirá) */ 

22099 bp = get_block(sp->s_dev, SUPERBLOCK, NORMAL); 

22100 memcpy( (char *) sp, bp->b_data, (size t) SUPERSIZE); 

22101 put_block(bP, ZUPER BLOCK) j 

22102 sp->s_dev = NO_DEV; /* restaurar después */ 

22103 magic = sp->s_magic; /* determina tipo de sistema arch */ 

22104 

22105 /* Obtener versión y tipo del sistema de archivos. */ 

22106 if (magic = SUPERMAGIC I ¡ magic == conv2(B YTESWAP, SUPERMAGIC» { 

22107 versión = VI ;j 

22108 native = (magic = SUPERMAGIC); 

22109 } else if (magic = SUPER V2 11 magic == conv2(B YTE SWAP, SUPER V2» { 

22110 versión = V2; 

22111 native = (magic = SUPER_V2); 

22112 } else { 

22113 retum(EINVAL); 

22114 } 

22115 

22116 /* Si el superbloque tiene el orden de bytes equivocado, intercambiar los campos; 

22117 * el número mágico no requiere conversión. */ 

22118 sp->s_ninodes = conv2(native, (int) sp->s_ninodes); 

22119 sp->s_nzones = conv2(native, (int) sp->s_nzones); 

22120 sp->s_imap_blockS = conv2(native, (int) sp->s_imap_blockS); 

22121 sp->s_zmap_blockS = conv2(native, (int) sp->s_zmap_blocks); 

22122 sp->s_firstdatazone = conv2(native, (int) sp->s_firstdatazone); 

22123 sp->s_log_zone_size = conv2(native, (int) sp->s_log_zone_size); 

22124 sp->s_max_size = conv4(native, sp->s_max_size); 

22125 sp->s_zones = conv4(native, sp->s_zones); 

22126 

22127 /* En VI, el tamaño de disp. se guarda en un short, s_nzones, lo que limitaba 

22128 * los dispositivos a 32K zonas. En V2 se decidió guardar el tamaño 

22129 * como long. Empero, cambiar s_nzones a long no funcionaría, pues entonces 

22130 * la posición de s_magic en el superbloque no sería la misma en los sistemas 

22131 * VI y V2, y no habría forma de saber si un sistema de archivos recién montado 

22132 * es VI o V2. La solución fue introducir una nueva variable, s_zones, 

22133 * Y copiar el tamaño ahí. 

22134 * 
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22135 * Calcular aquí también algunos otros números que dependen de la versión, 

22136 * para ocultar algunas de las diferencias. 

22137 */ 

22138 if (versión = VI) { 

22139 sp->s_zones = sp->s_nzones; /* sólo VI req esta copia */ 

22140 sp->s_inodes_per_block = VIINODESPERBLOCK; 

22141 sp->s~ndzones = V1NRD10NES; 

22142 sp->s_níndírs = V1INDIRECTS; 

22143 } else { 

22144 sp->s_inodes_per_block = V2_INODES_PER_BLOCK; 

22145 sp->s_ndzones = V2_NR_D10NES; 

22146 sp->s_nindirs = V2INDIRECTS; 

22147 } 

22148 

22149 sp->s_isearch = 0; /* búsquedas de nodos comienzan en 0 */ 

22150 sp->s_zsearch = 0; /* búsquedas de zonas comienzan en 0 */ 

22151 sp->s_version = versión; 

22152 sp->s_native = native; 

22153 

22154 /* Algunas verifs. básicas p/ver si el superbloque parece razonable. */ 

22155 if (sp->s_imap_blocks < 111 sp->s_zmap_blocks < 1 

22156 11 sp->s_ninodes <111 sp->s_zones < 1 

22157 11 (unsigned) sp->s_log_zone_size > 4) { 

22158 retum(EINVAL); 

22159 } 

22160 sp->s_dev = dev; /* restaurar número dispositivo */ 

22161 retum(OK); 

22162 } 


src/fs/filedes.c 


22200 

22201 

22202 

22203 

22204 

22205 

22206 

22207 

22208 

22209 

22210 
22211 
22212 
22213 


22214* get_fd 

22215 


22216 PUBLIC int get_fd(start, bits, k, fpt) 

22217 int start; /* inicio búsqueda (para FDUPFD) */ 

22218 modet bits; /* modo del arch a crear (bits RWX) */ 

22219 int *k; /* dónde devolver descriptor de arch */ 

22220 struct filp **fptj /* dónde devolver ranura filp */ 

22221 { 

22222 /* Buscar un descriptor de archivo libre y una ranura filp libre. Llenar palabra 

22223 * de modo en la última pero no apropiarse de ninguno, pues aún podría 

22224 * fallar el open() o creat(). 


/* Este archivo contiene los procedo que manipulan descriptores de arch. 

* Los puntos de entrada al archivo son 

* get_fd: buscar descriptor de archivo libre y ranuras filp libres 

* get_filp: buscar entrada filp p/descriptor de archivo dado 

* find_filp: encontrar ranura filp que apunte a un nodo-i dado 


#include "fs.h" 
#include "file.h" 
#include "fproc.h" 
#include "inode.h" 
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22225 

22226 

22227 

22228 

22229 

22230 

22231 

22232 

22233 

22234 

22235 

22236 

22237 

22238 

22239 

22240 

22241 

22242 

22243 

22244 

22245 

22246 

22247 

22248 

22249 

22250 

22251 

22252 

22253 

22254 

22255 

22256 

22257 
22260 


*/ 


register struct filp *f; 
register int i; 

*k = -1; /* necesitamos cómo saber si 

/* Buscar un descriptor de archivo libre en la tabla fproc fp_filp. */ 
for (i = startj i < OPEN_MAXj i++) { 

if (fp->fp_filp[i] =NIL_FILP) { 

/* Se encontró un descriptor de archivo. */ 

*k = i; 


/* Ver si se encontró un descriptor de archivo. */ 

if (*k < 0) retum(EMFILE); /* por esto hicimos k = -1 inic. */ 

/* Ahora que hallamos un descriptor de archivo, buscar ranura filp libre. */ 
for (f = &filp[0] j f < &filp[NR_FILPSlj f++) { 
if (f->filp_count == 0) { 

f->filp_mode = bits; 
f->filp_pos = 0L; 
f->filp_flags = 0; 

*fpt = f; 

retum(OK); 


} 

/* Si llegamos aquí, la tabla filp está llena. Informar de ello. */ 
retum(ENFILE); 

} 


¡ halló dése arch */ 


/*-= 


22261 * 

22262 

get_filp 


22263 PUBLIC struct filp *getJilp(fild) 

22264 int fild; /* descriptor de archivo */ 

22265 { 

22266 /* Ver si 'fild' se ref a un dése arch válido. Si sí, devolver su apunt filp. */ 

22267 

22268 erreode = EBAOF; 

22269 if (fild <011 fild >= OPEN_MAX ) retum(NIL_FILP); 

22270 retum(fp->fp filp[fild]); /* puede ser también NIL FILP -/ 

22271 } 

22274 


/*-= 


22275 * 

22276 

find_filp 


22277 PUBLIC struct filp *find_filp(rip, bits) 

22278 register struct inode *rip; /* nodo al que se ref el filp por hallar */ 

22279 Mode_t bits; /* modo del filp por hallar (bits RWX) */ 

22280 { 

22281 /* Encontrar una ranura filp que se refiera al nodo-i ’rip' tal como describe 

22282 * el bit de modo 'bit s'. Sirve p/determinar si alguien aún está interesado 

22283 * en cualquier extremo de un conducto. También se usa al abrir un FIFO para hallar 

22284 * con quién compartir un campo filp (p/compartir la posición en el archivo). 
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22285 * Al igual que 'get_fd', realiza una búsqueda lineal de la tabla filp. 

22286 */ 

22287 

22288 register struct filp *f; 

22289 

22290 for (f = &filp[0]; f < &filp[NR_FILPS]; f++) { 

22291 if’(f->filp_count != 0 && f->filp_ino = rip && (f->filp_mode & bitS)){ 

22292 retum(f); 

22293 } 

22294 } 

22295 

22296 /* Si llegamos aquí, no estaba ahí el filp. Informar de ello. */ 

22297 retum(NIL_FILP); 

22298 } 


src/fs/lock.c 


22300 /* Este archivo maneja candados asesores de archivos según exige POSIX. 

2230 * 

22302 * Los puntos de entrada a este archivo son 

22303 * 10Ck_op: realizar ops de candado para llamada al sistema FCNTL 

22304 * lock_revive: revivir procesos cuando se libera un candado 

22305 */ 

22306 

22307 #include "fs.h" 

22308 #include <fcntl.h> 

22309 #include <unistd.h> /* cc se queda sin memoria con unistd.h :-( */ 

22310 #include "file.h" 

22311 #include "íproc.h" 

22312 #include "inode.h" 

22313 #include "lock.h" 

22314 #include "param.h" 

22315 

22316 


22317 * 10Ck_op 

22318 

= = ====== = ==== = ==== = ====== = = = = == == = = = ===== = = = = == = = = = = = = == = == */ 

22319PU8LIC int 10Ck_op(f, req) 

22320 struct filp *f; 

22321 int req; /* F SETLK o bien F SETLKW */ 

22322 { 

22323 /* Aplicar los candados asesores requeridos por POSIX. */ 

22324 

22325 int r, ltype, i, conflict = 0, unlocking = 0; 

22326 mode t mo; 

22327 off_t first, last; 

22328 struct flock flock; 

22329 vir_bytes user_flock; 

22330 struct file_lock *flp, *flp2, *emptY; 

22331 

22332 /* Traer la estructura flock del espacio de usuario. */ 

22333 user_flock = (vir_bytes)namel; 

22334 r = sys_copy(who, D, (phys_bytes) user_flock, 

22335 FS_PROC_NR, D, (phys_bytes) &flock, (phys_bytes) Sizeof(flock)); 

22336 if (r 1= OK) retum(EINVAL); 

22337 

22338 /* Realizar algunas verificaciones de errores. */ 

22339 ltype = flock.ljype; 
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22340 mo = f->filp_mode; 

22341 if (ltype != F UNLCK && ltype != FRDLCK && ltype != FWRLCK) retum(EINVAL); 

22342 if (req = F_GETLK && ltype = F_UNLCK) retum(EINVAL); 

22343 if ( (f->filp_ino->i_mode & ITYPE) != I REGULAR) retum(EINVAL); 

22344 if (req != FGETLK && ltype = F RDLCK && (mo & R BIT) == 0) retum(EBADF); 

22345 if (req != F GETLK && ltype = F WRLCK && (mo & W BIT) = 0) retum(EBADF); 

22346 

22347 /* Calcular primero y último bytes de la región asegurada. */ 

22348 switch (flock.l_whence) { 

22349 case SEEK SET: fírst = 0; break; 

22350 case SEEK CUR: first = f->filp pos; break; 

22351 case SEEK=END: fírst = f->filp=ino->i_size; break; 

22352 default: retum(EINVAL); 

22353 } 

22354 /* Verificar si hay desbordamiento. */ 

22355 if (((long)flock.l_start > 0) && ((fírst + flock.l_start) < fírst)) 

22356 retum(EINVAL); 

22357 if (((long)flock.l_start < 0) && ((fírst + flock.l_start) > fírst)) 

22358 retum(EINVAL); 

22359 first = fírst + flock.l_start; 

22360 last = first + flock.l_len -1; 

22361 if (flock.l_len = 0) last = MAX FILE POS; 

22362 if (last < fírst) retum(EINVAL); 

22363 

22364 /* Ver si esta región está en conflicto con algún candado existente. */ 

22365 empty = (struct filejock *) 0; 

22366 for (flp = &file_lock[0]; flp < «fe file_lock[NR_LOCKS]; flp++) { 

22367 if (flp->lock_type = 0) { 

22368 if (empty = (struct filejock *) 0) empty = flp; 

22369 continué; /* 0 = ranura desocupada */ 

22370 } 

22371 if (flp->lockJnode != f->filp_ino) continué; /* diferente arch */ 

22372 if (last < flp->lock_fírst) continué; /* nuevo al frente */ 

22373 if (first > flp->lockJast) continué; /* nuevo está después */ 

22374 if (ltype = F RDLCK && flp->lockJype = F RDLCK) continué; 

22375 if (ltype != FJJNLCK && flp->lock_pid == fp->fp_pid) continué; 

22376 ' ~ 

22377 /* podría haber conflicto. Procesarlo. */ 

22378 conflict = 1; 

22379 if (req = F GETLK) break; 

22380 

22381 /* Si tratábamos de poner un candado, recién falló. */ 

22382 if (ltype = F RDLCK 11 ltype == F WRLCK) { 

22383 if (req = F SETLK) { 

22384 /* Para F SETLK, sólo informar fracaso. */ 

22385 retum(EAGAIN); 

22386 } else { 

22387 /* Para F_SETLKW, suspender el proceso. */ 

22388 suspend(XLOCK); 

22389 retum(O); 

22390 } 

22391 } 

22392 

22393 /* Estamos quitando un candado y encontramos algo que traslapa. */ 

22394 unlocking = 1; 

22395 if (first <= flp->lock_fírst && last >= flp->lockJast) { 

22396 flp->lockJype = 0; /* marcar ranura como desocupada */ 

22397 nrjocks—; /* núm candados ahora es 1 menos */ 

22398 continué; 

22399 } 
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22400 

22401 /* Parte de una región asegurada se desaseguró. */ 

22402 if (first <= flp->lock_first) { 

22403 flp->lock_fírst = last + 1; 

22404 continué; 

22405 } 

22406 

22407 if (last >= flp->lock_last) { 

22408 flp->lock_last = first -1; 

22409 continué; 

22410 } 

22411 

22412 /* Mala suerte. Candado partido en 2 al desasegurar en medio. */ 

22413 if (nr locks = NR_LOCKS) retum(ENOLCK); 

22414 for (i = 0; i < NR LOCKS; i++) 

22415 if (file_lock[i].lock_type == 0) break; 

22416 flp2 = &file_lock[i]; 

22417 flp2->lock_type = flp->lock_type; 

22418 flp2->lock_pid = flp->lock_pid; 

22419 flp2->lock_inode = flp->lock_inode; 

22420 flp2->lock_first = last + 1; 

22421 flp2->lock_last = flp->lock_last; 

22422 flp->lock_last = first -1; 

22423 nr_locks++; 

22424 } 

22425 if (unlocking) lock_revive(); 

22426 

22427 if (req = F GETLK) { 

22428 if (conflict) { 

22429 /* GETLK Y conflicto. Informar de candado en conflicto. */ 

22430 flock.l_type = flp->lock_type; 

22431 flock.l_whence = SEEKSET; 

22432 flock.l_start = flp->lock_first; 

22433 flock.l_len = flp->lock_last -flp->lock_first + 1; 

22434 flock.l_pid = flp->lock_pid; 

22435 

22436 } else { 

22437 /* Es GETLK y no hay conflicto. */ 

22438 flock.l_type = FUNLCK; 

22439 } 

22440 

22441 /* Copiar estructura flock de vuelta al invocador. */ 

22442 r = sys_copy (FSPROCNR , D, (phys_bytes) &flock, 

22443 who, D, (phys_bytes) user_flock, (phys_bytes) sizeof(flock»; 

22444 retum(r); 

22445 } 

22446 

22447 if (ltype = FUNLCK) retum(OK); /* desaseguró región sin candados */ 

22448 

22449 /* No hay conflicto. Si hay espacio, guardar nuevo candado en la tabla. */ 

22450 if (empty = (struct file_lock *) 0) retum(ENOLCK)j /* tabla llena */ 

22451 empty->lock_type = ltype; 

22452 empty->lock_pid = fp->fp_pid; 

22453 empty->lock_inode = f->filp_ino; 

22454 empty->lock_first = first; 

22455 empty->lock_last = last; 

22456 nr_locks++; 

22457 retum(OK); 

22458 } 
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22460 


22461 * lock_revive 

22462 


22463 PUBLIC void lock_revive() 

22464 { 

22465 /* Encontrar todos los procesos que están esperando por cualquier tipo 

22466 * de candado y'revivirlos. Los que aún estén bloqueados se bloquearán 

22467 * otra vez al ejecutarsej los demás acabarán. Esta estrategia es un trueque 

22468 * espacio-tiempo. Necesitaríamos código extra para saber exactamente 

22469 * cuáles desbloquear ahora, y sólo ganaríamos un poco en rendimiento 

22470 * en casos extremadamente raros (a saber, si alguien usó realmente 

22471 * candados.) 

22472 */ 

22473 

22474 inttask; 

22475 struct fproc *fptr; 

22476 

22477 for (fptr = &fproc[INIT_PROC_NR + l]j fptr< &fproC[NR_PROCSlj fptr++) { 

22478 task = -fptr->fp_task; 

22479 if (fptr->fp_suspended = SUSPENDED && task = XLOCK) { 

22480 revive( (int) (fptr -fproc), 0); 

22481 } 

22482 } 

22483 } 


src/fs/main.c 


22500 /* Este archivo contiene el programa principal del Sistema de Archivos. Consiste 

22501 * en un ciclo que obtiene mensajes que solicitan trabajo, realiza el trabajo y 

22502 * devuelve respuestas. 

22503 * 

22504 * Los puntos de entrada a este archivo son 

22505 * main: programa principal del Sistema de Archivos 

22506 * reply: enviar respuesta a un proc después de realizar trab solicitado 

22507 */ 

22508 

22509 struct super_block; /* proto.h necesita saber esto */ 

22510 

22511 #include "fs.h" 

22512 #include <fcntl.h> 

22513 #include <string.h> 

22514 #include <sys/ioctl.h> 

22515 #include <miníx/callnr.h> 

22516 #include <minix/com.h> 

22517 #include <minix/boot.h> 

22518 #include "buf.h" 

22519 #include "dev.h" 

22520 #include "file.h" 

22521 #include "fproc.h" 

22522 #include "inode.h" 

22523 #include "param.h" 

22524 #include "super.h" 

22525 


22526 FORWARD _PROTOTYPE( void buf_pool, (void) ) 

22527 FORWARD_PROTOTYPE( void fs_init, (void) ) 

22528 FORWARD _PROTOTYPE( void get_boot_parameters, (void) ) 

22529 FORWARD _PROTOTYPE( void get work, (void) ) 
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22530 FORWARD _PROTOTYPE( void loadram, (void) ); 

22531 FORWARD _PROTOTYPE( void load_super, (Dev_t super dev) ); 

22532 

22533 

22534 


22535 * 

22536 


22537 PUBLIC void main() 

22538 { 

22539 /* Este es el programa principal del sistema de archivos. El ciclo principal 

22540 * tiene 3 actividades principales: obtener nuevo trabajo, procesarlo y responder. 

22541 * El ciclo nunca termina en tanto se ejecuta el sistema de archivos. 

22542 */ 

22543 int error; 

22544 

22545 fs_init(); 

22546 

22547 /* Ciclo principal que obtiene trabajo, lo procesa y responde. */ 

22548 while (TRUE) { 

22549 get_work(); /* establece who y fs_call */ 

22550 

22551 fp = &fproc[who]; /* apunt a struct de tabla proc */ 

22552 super_user = (fp->fp_effuid = SUUID ? TRUE : FALSE); /* ¿su? */ 

22553 dont_reply = FALSE; /* o sea, responder es default */ 

22554 

22555 /* Llamar la función intema que realiza el trabajo. */ 

22556 if (fs_call <011 fs_call >= NCALLS) 

22557 error = EBADCALL; 

22558 else 

22559 error = (*call_vector[fs_call]) (); 

22560 

22561 /* Copiar resultados al usuario y enviar respuesta. */ 

22562 if (dont_reply) continué; 

22563 reply(who, error); 

22564 if (rdahed_inode != NIL_INODE) read_ahead(); /* leer blq anticip */ 

22565 } 

22566 } 

22569 


/*- 



22570 * 

22571 

get_work 

-*/ 


22572 PRIVATE void get_work() 

22573 { 

22574 /* Normalmente esperar nuevas entradas, pero si 'reviving' es dif. 

22575 * de cero, hay que despertar un proceso suspendido. 

22576 */ 

22577 

22578 register struct fproc *rp; 

22579 

22580 if (reviving 1= 0) { 

22581 /* Revivir un proceso suspendido. */ 

22582 for (rp = &fproc[0]; rp < &fprOC[NR_PROCS]; rp++) 

22583 if (rp->fp_revived = REVIVING) { 

22584 who = (int)(rp -fproc); 

22585 fs_call = rp->fp_fd & BYTE; 

22586 fd = (rp->fp_fd »8) & BYTE; 

22587 buffer = rp->fp_buffer; 

22588 nbytes = rp->fp_nbytes; 

22589 rp->fp_suspended = NOT SUSPENDED; /*ya no espera*/ 
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22590 rp->fp_revived = NOTREVIVINGj 

22591 reviving—; 

22592 retum; 

22593 } 

22594 panic("get_work couldn't revive anyone", NOJSÍUM); 

22595 } 

22596 

22597 /* Caso normal. Nadie a quien revivir. */ 

22598 if (receive(ANY, &m) != OK) panic("fs receive error", NO NUM); 

22599 

22600 who = m.msource; 

22601 fs_call = m.m_type; 

22602 } 

22605 


22606 * reply 

22607 


22608 PUBLIC void reply(whom, result) 

22609 int whom; /* proceso al cual responder */ 

22610 int result; /* resultado (usualmente OK o # error) */ 

22611 { 

22612 /* Enviar respuesta a proceso de usuario. Puede fallar (si el proceso 

22613 * acaba de matarse por una señal), así que no verificar el código de retomo. 

22614 * Si falla el envío, hacer caso omiso. 

22615 */ 

22616 

22617 replyjype = result; 

22618 send(whom, &ml); 

22619 } 

22622 


22623 * fs_init 

22624*=== = === == = = = == = = ========= 


22625 

22626 

22627 

22628 

22629 

22630 

22631 

22632 

22633 

22634 

22635 

22636 

22637 

22638 

22639 

22640 

22641 

22642 

22643 

22644 

22645 

22646 

22647 

22648 

22649 


PRIVATE void fs_init() 

{ 

/* Inicializar variables globales, tablas, etc. */ 
register struct inode *rip; 
message mess; 


/* Inicializaciones necesarias para que dev_opcl tenga éxito.*/ 
fp = (struct fproc *) NULL; 
who = FSPROCNR; 


buf_pool(); 

get_boot_parameters(); 
load_ram(); 

load_super(ROOT_DE V); 


/* inicializar reserva de buffers */ 
/* obtener parámetros del menú */ 
/* inic disco RAM, cargar si raíz */ 
/* cargar superbloque disp raíz */ 


/* Inicializar campos 'fproc' para proceso 0 ..INIT. */ 
for (i = Oj i <= LOW USER; /'+= 1) { 

if (i = FS_PROC_NR) continué; l~ no inicializar FS */ 

fp = &fproc[i]; 

rip = get inode (ROOT DEV , ROOT INODE); 
fp->fp_rootdir = rip; 

dup_inode(rip); 
fp->fp_workdir = rip; 
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22650 fp->fp_realuid = (uid_t) SYS_UID; 

22651 fp->fp_effuid = (uid_t) SYS_UID; 

22652 fp->fp_realgid = (gid_t) SYS_GID; 

22653 fp->fp_effgid = (gid_t) SYS_GID; 

22654 fp->fp_umask = -0; 

22655 } 

22656 

22657 {* Deben cúmplirse ciertas relaciones para que el FS funcione. * { 

22658 if (SUPERSIZE > BLOCKSIZE) panic("SUPER_SIZE > BLOCKSIZE", NO_NUM); 

22659 if (BLOCK SIZE % V2 INODE SIZE != 0) {* verif VIJNODESIZE también * { 

22660 panic("BLOCK_SIZE % V2 INODE SIZE != 0", NO_NUM); 

22661 if (OPEN_MAX > 127) panic("OPEN_MAX > 127", NO_NUM); 

22662 if (NR BUFS < 6) panic("NR_BUFS < 6", NO_NUM); 

22663 if (VIJNODESIZE != 32) panic("Vl inode size 1= 32", NO_NUM); 

22664 if (V2 INODE SIZE != 64) panic("V2 inode size 1= 64", NO_NUM); 

22665 if (OPEN_MAX > 8 * sizeof(long» panic("Too few bits in fpcloexec", NO_NUM); 

22666 

22667 {* Decir tarea de memoria dónde está mi tabla de proc para benef ps(l). * { 

22668 mess.m type = DEVJOCTL; 

22669 mess.PROCNR = FS_PROC_NR; 

22670 mess.REQUEST = MIOCSPSINFO; 

22671 mess.ADDRESS = (void *) fproc; 

22672 (void) sendrec(MEM, &mess); 

22673 } 

22676 


22677 * buf_pool 

22678*== = = = = = === = === = == = = = == = = == == = == = ===== = === 

=*/ 

22679 PRIVATE void buf_pool() 

22680 { 

22681 {* Inicializar la reserva de buffers. * { 

22682 

22683 register struct buf *bp; 

22684 

22685 bufs_in_use = 0; 

22686 front = &buf[0]; 

22687 rear = &bufINR_BUFS . 1 ]; 

22688 

22689 for (bp = «febuflO]; bp < &bufINR_BUFS]; bp++) { 

22690 bp->b_blocknr = NOBLOCK; 

22691 bp->b_dev = NO_DEV; 

22692 bp->b_next = bp + 1; 

22693 bp->b_prev = bp -1; 

22694 } 

22695 buf[0] ,b_prev = NIL BUF; 

22696 buf[NR_BUFS -1] ,b_next = NIL BUF; 

22697 

22698 for (bp = &bufI0]; bp < &buf[NR_BUFS]; bp++) bp->b_hash = bp->b_next; 

22699 buf_hash[0] = front; 

22700 } 

22703 


22704 * get_boot_parameters 

22705 * === === == = === = = ■= = 

7 

22706 PUBLIC struct bparam s boot_parameters; 

22707 

22708 PRIVATE void get_boot_parameters() 

22709 { 








832 


Archivo: 


src/fs/main.c EL CÓDIGO FUENTE DE MINIX 

22710 /* Pedir al kemel parámetros de arranque. */ 

22711 

22712 mi.m type = SYS_GBOOT; 

22713 mi .PROC1 = FS_PROC_NR; 

22714 ml.MEM_PTR = (char *) &boot_parameters; 

22715 (void) sendrec(SYSTASK, &ml); 

22716 } 

22719 

22720 * load ram * 

22721 


22722 PRIVATE void load_ram() 

22723 { 

22724 /* Si el disp raiz es el disco RAM, copiar todo el disp de imagen raiz 

22725 * bloque por bloque en un disco RAM con el mismo tamaño que la imagen. 

22726 * Si no, asignar un disco en RAM con el tamaño dado en paráms de arranque. 

22727 */ 

22728 

22729 register struct buf *bp, *bpl; 

22730 long k_loaded, lcount; 

22731 u32_t ram_size, fsmax; 

22732 zone_t zones; 

22733 struct super_block *sp, *dsp; 

22734 block_t b; 

22735 int majar, task; 

22736 message dev_mess; 

22737 

22738 ramsize = boot_parameters.bp_ramsize; 

22739 

22740 /* Abrir el dispositivo raíz. */ 

22741 majar = (ROOT_DEV » MAJOR) & BYTE; /* núm de dispositivo principal */ 

22742 task = dmapjmajor] ,dmap_task; /* núm de tarea de dispositivo */ 

22743 dev_mess.m_type = DEV_OPEN; /* distinguir de cerrar */ 

22744 devmess.DEVICE = ROOTDEV; 

22745 devmess.COUNT = RBITIWBIT; 

22746 (*dmap[major] .dmap_open) (task, &dev_mess); 

22747 if (dev_mess.REP_STATUS 1= OK) paníc("Cannot open root device",NO_NUM); 

22748 

22749 /* Si el disp raíz es el disco RAM, llenarlo del dispositivo de imagen. */ 

22750 if (ROOT DEV == DEV RAM) { 

22751 majar = (IMAGEDEV » MAJOR) & BYTE; /* núm disp principal */ 

22752 task = dmapjmajor] ,dmap_task; /* núm tarea de disp */ 

22753 dev iness.m type = DEVOPEN; /* distinguir de cerrar */ 

22754 devmess.DEVICE = IMAGEDEV; 

22755 devmess.COUNT = RBIT; 

22756 (*dmap[major] ,dmap_open) (task, &dev_mess); 

22757 if (dev mess.REP STATUS != OK) panic("Cannot open root device", NO_NUM); 

22758 

22759 /* Obtener tamaño de disco RAM leyendo superbloque de sist arch raíz. */ 

22760 sp = &super_block[0]; 

22761 sp->s_dev = IMAGEDEV; 

22762 if (read_super(sp) 1= OK) panic("Bad root file System", NO_NUM); 

22763 

22764 lcount = sp->s_zones«sp->s_log_zone_size; /* # blqs disp raíz*/ 

22765 

22766 /* Estirar el FS del disco en RAM al tamaño dado por los paráms de arranque, 

22767 * pero no más allá de lo que permite el últ. bloque del mapa de bits de zonas. 

22768 */ 

22769 if (ram_size < lcount) ram_size = lcount; 
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22770 fsmax = (u32_t) sp->s_zmap_blocks * CHAR BIT * BLOCKSIZE; 

22771 fsmax = (fsmax + (sP->s_firstdatazone-l)) « sp->s_log_zone_size; 

22772 if (ram size > fsmax) ramsize = fsmax; 

22773 } 

22774 

22775 /* Decir al controlador de RAM qué tamaño debe tener el disco en RAM. */ 

22776 mi .mtype = DEVIOCTLj 

22777 mi ,PROC_NR = FS_PROC_NR; 

22778 mi .REQUEST = MIOCRAMSIZE; 

22779 ml.POSITION = ramsize; 

22780 if (sendrec(MEM, &ml) != OK 11 ml.REP STATUS != OK) 

22781 panic("Can’t set RAM disk size", NO_NUM); 

22782 

22783 / * Dar a MM tamaño de disco RAM, y esperar que entre "en línea". */ 

22784 mi.ml il = ((long) ram size * BLOCK SIZE) » CLICK SHIFT; 

22785 if (sendrec(MM_PROC_NR, &ml) != OK) 

22786 panic("FS can’t sync up with MM", NO_NUM); 

22787 

22788 /* Si el disp raíz no es el disco RAM, no necesita cargarse. */ 

22789 if (ROOT DEV != DEV RAM) returnj 

22790 

22791 /* Copiar bloques 1 por 1 de la imagen al disco en RAM. */ 

22792 printf("Loading RAM disk.\33[23CLoaded: OK"); 

22793 

22794 inode[0] .i mode = I BLOCK SPECLAL; /* nodo-i temp para rahead() */ 

22795 inode[0] ,i_size = LONGMAX; 

22796 inode[0] .i_dev = IMAGEDEV; 

22797 inode[0] .i_zone[0] = IMAGE DEV; 

22798 

22799 for (b = 0; b < (block t) lcount; b++) { 

22800 bp = rahead(&inode[0], b, (off_t)BLOCK_SIZE * b, BLOCK SIZE); 

22801 bp 1 = get_block(ROOT_DEV, b, NOREAD); 

22802 memcpy(bpl->b_data, bp->b_data, (size t) BLOCK SIZE); 

22803 bpl->b_dirt = DIRTY; 

22804 put_block(bp, FULLDATABLOCK); 

22805 put_block(bp 1, FULL DATA BLOCK); 

22806 k loaded = ( (long) b * BLOCK_SIZE)/l 024L; /* K cargados */ 

22807 if (kjoaded % 5 = 0) printf("\b\b\b\b\b\b\b%51dK", kjoaded); 

22808 } 

22809 

22810 printf("\rRAM disk loaded.\33[K\n\n"); 

22811 

22812 /* Cerrar e invalidar dispositivo de imagen. */ 

22813 dev_mess.m_type = DEV CLOSE; 

22814 dev mess.DEVICE = IMAGE DEV; 

22815 (*dmap[major] ,dmap_close) (task, &dev_mess); 

22816 invalidate(IMAGE_DE V); 

22817 

22818 /* Redimensionar el sistema de archivos raíz del disco en RAM. */ 

22819 bp = get_bloCk(ROOT_DEV, SUPER BLOCK, NORMAL); 

22820 dsp = (struct super_block *) bp->b_data; 

22821 zones = ram_size » Sp->s_log_zone_size; 

22822 dsp->s_nzones = conv2(sp->s_native, (ul6_t) zones); 

22823 dsp->s_zones = conv4(sp->s_native, zones); 

22824 bp->b_dirt = DIRTY; 

22825 put_block(bp, ZUPER BLOCK); 

22826 } 

22829 



834 


Archivo: src/fs/main.c 


EL CÓDIGO FUENTE DE MINIX 


22830 * load_super 

22831 


22832 PRIVATE void load_super(super_dev) 

22833 dev_t super_dev; /* de dónde obtener 

superbloque */ 

22834 { 

22835 intbad; 

22836 register struct super_block *sp; 

22837 register struct inode *rip; 

22838 

22839 /* Inicializar la tabla de superbloques. */ 

22840 for (sp = &super_block[0]; sp < &super_block[NR_SUPERS]; sp++) 

22841 sp->s_dev = NODEV; 

22842 

22843 /* Leer superbloque para sistema de archivos raíz. */ 

22844 sp = &super_block[0]; 

22845 sp->s_dev = super_dev; 

22846 

22847 /* Verif. consistencia superbloque (¿es el disquete correcto?). */ 

22848 bad = (read_super(sp) != OK); 

22849 if (!bad) { 

22850 rip = get_inode(super_dev, ROOT_INODE); /* nodo-i de dir raíz */ 

22851 if ( (rip->i_mode & I_TVPE) != I_DIRECTORV 11 rip->i_nlinks < 3) bad++; 

22852 } 

22853 if (bad)panic('Tnvalid root fde system. Possibly wrong diskette.",NO_NUM); 

22854 

22855 sp->s_imount = rip; 

22856 dup_inode(rip); 

22857 sp->s_isup = rip; 

22858 sp->s_rd_only = 0; 

22859 retum; 

22860 } 


src/fs/open.c 


22900 /* Este archivo contiene los procedimientos para crear, a 

22901 * Y realizar búsquedas en archivos. 

22902 * 

22903 * Los puntos de entrada a este archivo son 
ejecutar llamada al sistema CREAT 
ejecutar llamada al sistema OPEN 
ejecutar llamada al sistema MKNOD 
ejecutar llamada al sistema MKDIR 
ejecutar llamada al sistema CLaSE 
ejecutar llamada al sistema LSEEK 


do_open: 

domknod: 

do_mkdir: 

do_clase: 

do_lseek: 


22904 

22905 

22906 * 

22907 * 

22908 * 

22909 * 

22910 */ 

22911 

22912 #include "fs.h" 

22913 #include <sys/stat.h> 22914 #include <fcntl.h> 

22915 #include <minix/callnr.h> 

22916 #include <minix/com.h> 

22917 #include "buf.h" 

22918 #include "dev.h" 

22919 #include "file.h" 
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22920 #include "fproc.h" 22921 #include "inode.h" 22922 #include "lock.h" 

22923 #include "param.h" 

22924 

22925 PRIVATE message dev mess; 

22926 PRIVATE char mode_roap[] = {R BIT, W_BIT, R BITIW BIT, 0}; 

22927 

22928 

FORWARD _PROTOTYPE( int commonopen, (int oflags, Modet omode) ); 

22929 FORWARD _PROTOTYPE( int pipe_open, (struct inode *rip,Mode_t bits,int oflags)); 

22930 FORWARD _PROTOTYPE( struct inode *new_node, (char *path, Mode t bits, 

22931 zonet zO) )j 

22932 

22933 

22934 

22935 * do_creat 

22936 


22937 PUBLIC int do_creat() 

22938 { 

22939 /* Ejecutar la llamada al sistema creat(name, mode). */ 

22940 int r; 

22941 

22942 if (fetch_name(name, name_length, M3) != OK) retum(err_code); 

22943 r = common_open(0_WRONLY I OCREAT I 0_TRUNC, (mode_t) mode); 

22944 return(r); 

22945 } 

22948/*====================== == =============== == ===== 

22949 * do_open 

22950*=============================== = ======= = == 

=*/ 22951 PUBLIC int do_open() 

22952 { 

22953 / * Realizar la llamada al sistema open(name, flags,...). */ 

22954 

22955 int create_mode = 0; /* realmente mode_t pero da problemas */ 

22956 int r; 

22957 

22958 /* Si 0_CREAT es 1, open tiene 3 parámetros, si no, 2. */ 

22959 if (mode & O CREAT) { 

22960 createmode = cmode; 

22961 r = fetch_name(c_name, namel_length, MI); 

22962 } else { 

22963 r = fetch_name(name, name_length, M3); 

22964 } 

22965 

22966 if (r != OK) retum(err_code); /* nombre erróneo */ 

22967 r = common_open(mode, create mode); 

22968 retum(r); 

22969 } 

22972/*= = =================== == ============== == ===== 

22973 * common open 

22974 


22975 PRIVATE int common_open(oflags, omode) 

22976 register int oflags; 

22977 mode_t omode; 

22978 { 

22979 /* Código común de do_creat y do_apeno */ 
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23022 
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register struct inode *rip; 

int r, b, major, task, exist = TRUE; 

dev_t dev; 

mode_t bits; 

offt pos; 

struct fdp *fil_ptr, *filp2; 

/* Remapear los dos bits inferiores de oflags. */ 
bits = (mode t) mode map[oflags & O ACCMODE]; 

/* Ver si están disponibles descriptor de archivo y ranuras filp. */ 
if ( (r = get_fd(0, bits, &fd, &fil_ptr)) != OK) retum(r); 

/* Si O CREATE es 1, tratar de crear el archivo. */ 
if (oflags & O CREAT) { 

/* Crear nodo-i nuevo invocando new_node(). */ 

omode = IREGULARI (omode & ALL MODES & fp->fp_umask); 

rip = new_node(user_path, omode, NO_10NE); 

r = err_code; 

if (r = OK) exist = FALSE; /* recién creamos el archivo */ 

else if (r != EEXIST) retum(r); /* otro error */ 

else exist = ! (oflags & 0_EXCL); /* archivo existe; si bandera 0_EXCL 

} else { 

/* Examinar nombre de ruta. */ 

if ( (rip = eat_path(user_path)) ~NIL INODE) retum(err_code); 

} 

/* Apartar descriptor de archivo y ranura filp y llenarlos. */ 

fp->fp_filp[fd] = fil_ptr; 

fil_ptr->filp_count = 1; 

fil_ptr->filp_ino = rip; 

fil_ptr->filp_flags = oflags; 

/* Sólo ejecutar código de open normal si no creamos el archivo. */ 
if (exist) { 

/* Verificar protecciones. */ 

if ((r = forbidden(rip, bits)) = OK) { 

/* Apertura archs normales, dirs y archs esp. difiere. */ 
switch (rip->i_mode & I_TYPE) { 
case I REGULAR: 

/* Truncar arch normal si 0_TRUNCo */ 
if (oflags & O TRUNC) { 

if ((r = forbidden(rip, W BIT)) !=OK) break; 
truncate(rip); 
wipe_inode(rip); 

/* Enviar nodo-i de caché de nodos-i 
* al caché de bloques pique se escriba en sigte 
* desalojo de caché. 

*/ 


Mnode(rip, WRITING); 




:e I DIRECTORY: 

/* Directorios pueden leerse pero no escribirse. */ 
r = (bits & W BIT ? EISDIR : OK); 
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23040 

23041 

23042 

23043 

23044 

23045 

23046 

23047 

23048 

23049 

23050 

23051 

23052 

23053 

23054 

23055 

23056 

23057 

23058 

23059 

23060 

23061 

23062 

23063 

23064 

23065 

23066 

23067 

23068 

23069 

23070 

23071 

23072 

23073 

23074 

23075 

23076 

23077 

23078 

23079 

23080 

23081 

23082 

23083 

23084 

23085 

23086 

23087 

23088 

23089 

23090 

23091 

23092 

23093 } 

23094 } 

23095 

23096 /* Si hay 


case I CHAR SPECIAL: 
case I BLOCK SPECLAL: 

/* Invocar controlador p/procesam. especial. */ 
devmess.mtype = DEVOPEN; 
dev = (dev_t) rip->i_zone[0]; 
devmess.DEVICE = dev; 

dev mess.COUNT = bits I (oflags & -0_ACCMODE); 
majar = (dev» MAJOR) & BYTE; /* # dispprinc */ 
if (major <=011 majar >= max major) { 
r = ENODEV; 

} 

task = dmap[major] ,dmap_task; /* # tarea disp */ 

(*dmap[major] ,dmap_open) (task, &dev_mess); 
r = devmess.REPSTATUS; 

case INAMEDPIPE: 

oflags 1= OAPPEND; /* modo anexión forzada */ 

fil_ptr->filp_flags = oflags; 
r = pipe_open(rip, bits, oflags); 
if (r = OK) { 

/* Ver si alguien más lee o escribe en FIFO. 

* Si sí, usar su entrada filp pique la posición 

* de archivo se comparta automáticamente. 

*/ 

b = (bits & RBIT ? RBIT : W_BIT); 
fil_ptr->filp_count = 0; /* no se encuentra */ 

if ((ñlp2 = fmd_filp(rip, b)) != NIL_FILP) { 

/* Coescritor o lector hallado. Usarlo.*/ 
fp->fp_filp[fd] = filp2; 

filp2->filp_count++; 
filp2->filp_ino = rip; 
filp2->filp_flags = oflags; 

/* eatpath incrementó i_count 

* erróneamente porque no sabia 

* que íbamos a usar una entrada 

* filp existente. Corregir. 

rip->i_count-; 

} else { 

/* Nadie más hallado. Restaurar f~lp. */ 
fil_ptr->filp_count = 1; 
if (b = RBIT) 

pos = rip->i_zone[V2_NR_DZONES+l ]; 

pos = rip->i_zone [V 2NRDZONES+2]; 
fil_ptr->filp_pos = pos; 

} 

} k 


23097 if (r != OK) { 

23098 fp->fp_fílp[fd] = NILFILP; 

23099 fil_ptr->filp_count= 0; 
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23100 put_inode(rip); 

23101 retum(r); 

23102 } 

23103 

23104 retum(fd); 

23105 } 

23108 


23109 * new_node 

23110 


23111 PRIVATE struct inode *new_node(path, bits, zO) 

23112 char *path; /* apunt a nombre de ruta */ 

23113 mode_t bitsj /* modo del nuevo nodo-i */ 

23114 zone_t zOj /* núm zona 0 p/nuevo nodo-i */ 

23115 { 

23116 /* New_node() es invocado por common_open(), do_mknod() Y do_mkdir(). 

23117 * En todos los casos asigna un nuevo nodo-i, crea una entrada de directorio 

23118 * p/él en la ruta ’path' y la inicializa. Devuelve un apunt al nodo-i 

23119 * si puede hacer esto; si no, devuelve NIL_INODE. Siempre asigna 

23120 * valor apropiado a ’err_code' (OK o código de error). 

23121 */ 

23122 

23123 register struct inode *rlast_dir_ptr, *rip; 

23124 register int r; 

23125 char string[NAME_MAX]; 

23126 

23127 /* Ver si la ruta puede abrirse hasta el últ. directorio. */ 

23128 if ((rlast_dir_ptr = last_dir(path, string)) = NIL_INODE) retum(NIL_INODE); 

23129 

23130 /* Directorio final accesible, obtener componente final de la ruta. */ 

23131 rip = advance(rlast_dir_ptr, string); 

23132 if ( rip = NILINODE && err code = ENOENT) { 

23133 /* Últ. comp. de ruta no existe. Crear nueva entrada directorio. */ 

23134 if ( (rip = alloc_inode(rlast_dir_ptr->i_dev, bits)) — NIL_INODE) { 

23135 /* Imposible crear nuevo nodo-i: no hay más. */ 

23136 put_inode(rlast_dir_ptr); 

23137 retum(NIL_INODE); 

23138 } 

23139 

23140 /* Forzar nodo-i a disco antes de crear entrada de directorio 

23141 * para hacer al sistema más robusto ante caídas: un nodo-i 

23142 * sin entrada de directorio es mucho mejor que lo contrario. 

23143 */ 

23144 rip.>i_nlinks-H-; 

23145 rip->i_zone[0] = zO; /* núms disp principal/secund */ 

23146 rw_inode(rip, WRITING); /* forzar nodo-i a disco ahora */ 

23147 

23148 /* Nuevo nodo-i adquirido. Tratar de crear entrada directorio. */ 

23149 if ((r = search_dir(rlast_dir_ptr, string, &rip->i_num,ENTER)) 1= OK) { 

23150 put_inode(rlast_dir_ptr); 

23151 rip->i_nlinks—; /* lástima, hay que liberar nodo-i */ 

23152 rip->i_dirt = DIRTY; /* nodos-i sucios se escriben */ 

23153 put_inode(rip)j /* esta llamada libera el nodo-i */ 

23154 err_code = r; 

23155 retum(NIL_INODE); 

23156 } 

23157 

23158 } else { 

23159 /* El último componente existe o hay algún problema. */ 
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23160 

if (rip != NIL INODE) 


23161 

r = EEXIST; 


23162 

else 


23163 

r = err code; 


23164 

} 


23165 



23166 

/* Devolver el nodo-i de directorio y salir. */ 


23167 

put inode(rlast dir_ptr); 


23168 

err code = r; 


23169 

retum(rip); 


23170 

} 


23173 



23174 

* pipeopen 

* 

231,3 



23176 

PRIVATE int pipe open(rip, bits, oflags) 


23177 

register struct inode *rip; 


23178 

register mode tbits; 


23179 

register int oflags; 


23180 

{ 


23181 

/* Esta función se llama desde common open. Ve si hay 


23182 

* por lo menos un par lector/escritor para el conductoj si no, 


23183 

* suspende al invocador, si sí, revive todos los demás procesos 


23184 

* bloqueados que esperan el conducto. 


23185 

*/ 


23186 



23187 

if (find filp(rip, bits «fe W BIT ? R BIT : W BIT) = NIL FILP) { 


23188 

if (oflags «fe O NONBLOCK) { 


23189 

if (bits «fe W BIT) retum(ENXIO); 


23190 

} else 


23191 

suspend(XPOPEN); /* suspender invocador */ 


23192 

} else if (susp_count > 0) {/* revivir procesos bloqueados */ 


23193 

release(rip, OPEN, susp_count); 


23194 

release(rip, CREAT, susp count); 


23195 

} 


23196 

rip-Npipe = IPIPE; 


23197 



23198 

retum(OK); 


23199 

B } 




=*23203 

* do_mknod 


23204 







23205 PUBLIC int do_mknod() 

23206 { 

23207 /* Realizar la llamada al sistema mknod(name, mode, addr). */ 

23208 

23209 register mode_t bits, mode_bits; 

23210 struct inode *ip; 

23211 

23212 /* Sólo el superusuario puede crear nadas que no sean fifos. */ 

23213 mode_bits = (mode_t) m.ml_i2; /* modo del nodo-i */ 

23214 if (¡super user «fe«fe ((mode_bits «fe ITYPE) != INAMEDPIPE)) retum(EPERM); 

23215 if (fetch_name(m.ml_pl, m.ml_il, MI) != OK) return(err_code); 

23216 bits = (mode bits «fe I TYPE) I (mode bits «fe ALL MODES «fe fp->fp_umask); 

23217 ip = new_node(uSer_path, bits, (zone_t) m.ml_i3); 

23218 put_inode(ip); 

23219 retum(err_code); 
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23220 } 

23223 


23224 * do_mkdir 

23225 

23226 PUBLIC int do_mkdir() 

23227 { 

23228 /* Ejecutar llamada al sistema mkdir(name, mode). *1 

23229 

23230 int rl, r2; 1 * códigos de situación */ 

23231 ino_t dot, dotdot; 1 *núms nodos-i para, y ..*/ 

23232 mode_t bits; /* bits de modo p/nuevo nodo-i */ 

23233 char string[NAME_MAX]; /* últ. comp de nombre ruta nuevo dir *1 

23234 register struct inode *rip, *ldirp; 

23235 

23236 /* Ver si es posible crear otro vínculo en dir padre. */ 

23237 if (fetch_name(namel, namel_length, MI) != OK) retum(err_code); 

23238 ldirp = last_dir(user_path, string); /* apunt a padre de nuevo dir *1 

23239 if (ldirp = NIL_INODE) retum(err_code); 

23240 if ( (ldirp->i_nlinks & BYTE) >= LINK MAX) { 

23241 put_inode(ldirp); /* devolver padre */ 

23242 retum(EMLINK); 

23243 } 

23244 

23245 /* Ahora crear nodo-i. Si fracasa, devolver código de error. */ 

23246 bits = IDIRECTORY 1 (mode & RWX MODES & fp->fp_umask); 

23247 rip = new_node(user_path, bits, (zone_t) 0); 

23248 if (rip = NILINODE 11 err code = EEXIST) { 

23249 put_inode(rip); /* imposible crear dir; ya existe *1 

23250 put_inode(ldirp); /* devolver padre también *1 

23251 retum(err_code); 

23252 } 

23253 

23254 /* Obtener núms nodo-i para, y ..p/colocar en directorio. */ 

23255 dotdot = ldirp->i_num; /* núm nodo-i del padre */ 

23256 dot = rip->i_num; /* núm nodo-i nuevo dir mismo */ 

23257 

23258 /* Crear entradas dir para, y ..a menos que disco totalmente lleno. */ 

23259 /* Usar dotl y dot2, así que el modo del dir no es importante. */ 

23260 rip->i_mode = bits; /* fijar modo */ 

23261 rl = search_dir(rip, dotl J &dot, ENTER); 1 * poner, en nvo dir *1 

23262 r2 = search_dir(rip, dot2, &dotdot, ENTER); /* poner., en nvo dir */ 

23263 

23264 /* Si se ingresaron, y ..con éxito, increm. cuentas de vínculos. */ 

23265 if (rl == OK && r2 = OK) { 

23266 /* Caso normal: pudimos ingresar, y ..en nuevo dir. */ 

23267 rip->i_nlinks++; /* esto da cuenta de .*/ 

23268 ldirp->i_nlinks-H-; /* esto da cuenta de ..*/ 

23269 ldirp->i_dirt = DIRTY; 1 * marcar nodo-i padre c/sucio */ 

23270 } else { 

23271 /* No pudimos ingresar, ni..; quizá disco lleno. */ 

23272 (void) search_dir(ldirp, string, (ino_t *) 0, DELETE); 

23273 rip->i_nlinks—; /* anular incremento en new_node() */ 

23274 } 

23275 rip->i_dirt = DIRTY; 1 * como sea, i_nlinks ha cambiado *1 

23276 

23277 put_inode(ldirp); /* devolver nodo-i de dir padre *1 

23278 put_inode(rip); 1 * devolver nodo-i de dir nuevo */ 

23279 retum(err_code); 1 * new_node() siempre fija ,err_code' */ 
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23280 } 

23283 *= 

23284 * 

23285 *= 


do_clase 


23286 PUBLIC int do_close(), 

23287 { 

23288 /* Ejecutar la llamada al sistema close(fd). */ 

23289 

23290 register struct fdp *rfilp; 

23291 register struct inode *rip; 

23292 struct file_lock *flp; 

23293 int rw, mode_word, majar, task, lock_count; 

23294 dev_t dev; 

23295 

23296 /* Primero encontrar nodo-i que pertenece al descriptor de archivo. */ 

23297 if ( (rfilp = get_ñlp(fd)) = NIL_FILP) retum(err_code); 

23298 rip = rfilp->filp_ino; /* ’rip' apunta al nodo-i */ 

23299 

23300 if (rfilp->filp_count -1 = 0 && rfilp->fúp_mode 1= FILP CLOSED) { 


IBLOCKSPECIAL) { 


i especial 


/* Ver si el archivo es especial. */ 
modeword = rip->i_mode & I TYPE; 
if (mode word — ICHARSPECLAL 11 mode word 
dev = (devt) rip->i_zone[0]; 
if (mode word = I BLOCK SPECIAL) { 

/* Invalidar entradas de caché a menos que 
* esté montado o sea ROOT 

if (!mounted(rip)) { 

(void) do_sync(); /* purgar cí 

invalidate(dev); 

} 

} 

/* Usar entrada dmap_close para realizar cualquier procesamiento 
* especial que se requiera. 


23301 

23302 

23303 

23304 

23305 

23306 

23307 

23308 

23309 

23310 

23311 

23312 

23313 

23314 

23315 

23316 

23317 

23318 

23319 

23320 

23321 

23322 

23323 

23324 

23325 /* Si el nodo que se cierra es conducto, liberar a todos los que lo esperan. */ 

23326 if (rip->i_pipe = I PIPE) { 

23327 rw = (rfilp->filp_mode & RBIT ? WRITE : READ); 

23328 release(rip, rw, NR_PROCS); 

23329 } 

23330 

23331 /* Si se escribió, el nodo-i ya está marcado DIRTY. */ 

23332 if (—rfilp->filp_count = 0) { 

23333 if (rip->i_pipe == I_PIPE && rip->i_count > 1) { 

23334 /* Guardar la pos. en el arch en el nodo-i en caso de que se nece 

23335 * site después. Las pos. de lectura y escrit se guardan aparte. 

23336 * Las últ. 3 zonas del nodo-i no se usan p/conductos (nombrados). 

23337 */ 

23338 if (rfilp->filp_mode = RBIT) 

23339 rip->i_zone[V2_NR_DZONES+l] = (zone_t) rfilp->filp_pos; 


} 


} 


dev_mess.m_type = DEV_CLOSE; 
dev mess.DEVICE = dev; 
majar = (dev » MAJOR) & BYTE; 
task = dmapjmajor] ,dmap_task; /* núm ta 

(*dmap[major] ,dmap_close) (task, &dev_mess); 


n disp principal */ 
:a disp */ 
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23340 else 

23341 rip->i_zone[V2_NR_DZONES+2] = (zone_t) rfilp->filp_pos; 

23342 } 

23343 put_inode(rip); 

23344 } 

23345 

23346 fp->fp_cloe~ec &=-(1L « fd); /* apagar bit cerrar-al-ejec */ 

23347 fp->fp_filp[fd] = NILFILP; 

23348 

23349 /* Ver si el archivo tiene candado. Soltar candados si los hay. */ 

23350 if (nr_locks == 0) return(OK); 

23351 lock_count = nr_locks; /* guardar cuenta candados */ 

23352 for (flp = &file_lock[0]; flp < &file_lock[NR_LOCKS]; flp++) { 

23353 if (flp->lock_type == 0) continué; /* ranura no en uso */ 

23354 if (flp->lock_inode = rip && flp->lock_pid = fp->fp_pid) { 

23355 flp->lock_type = 0; 

23356 nrjocks-; 

23357 } 

23358 } 

23359 if (nrjocks < lock_count) lock_revive(); /* candado liberado */ 

23360 retum(OK); 

23361 } 

23364 *========================================================= == = 

23365 * dolseek * 

23366 *======== = ===================== = ============================= == • 

23367 PUBLIC int do_lseek() 

23368 { 

23369 /* Ejecutar llamada al sistema lseek(ls_fd, offset, whence). */ 

23370 

23371 register struct filp *rfilp; 

23372 register off t pos; 

23373 

23374 /* Ver si el descriptor de archivo es válido. */ 

23375 if ( (rfilp = get_filp(ls_fd)) = NIL_FILP) retum(err_code); 

23376 

23377 /* No lseek en conductos. */ 

23378 if (rfilp->filp_ino->i_pipe = I PIPE) retum(ESPIPE); 

23379 

23380 /* El valor de 'whence' determina la posición inicial. */ 

23381 switch(whence) { 

23382 case 0: pos = 0; break; 

23383 case 1: pos = rfilp->filp_pos; break; 

23384 case 2: pos = rfilp->filp_ino->i_size; break; 

23385 default: retum(EINVAL); 

23386 } 

23387 

23388 /* Verificar desbordamiento. */ 

23389 if (((long)offset > 0) && ((long) (pos + offset) < (long)pos)) retum(EINVAL); 

23390 if (((long)offset < 0) && ((long)(pos + offset) > (long)pos)) retum(EINVAL); 

23391 pos = pos + offset; 

23392 

23393 if (pos l=rfilp->filp_pos) 

23394 rfilp->filp_ino->i_seek = ISEEK; /* inhibir lect adel. */ 

23395 rfilp->filp_pos = pos; 

23396 reply_l 1 = pos; /* insertar long en mensaje salida */ 

23397 retum(OK); 

23398 } 
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src/fs/read.c 


23400 /* Este archivo contiene el corazón del mecanismo para leer (y escribir) 

23401 * archivos. Las solicitudes se dividen en trozos que no cruzan 

23402 * fronteras de bloque. Cada trozo se procesa por tumo, también se detectan 

23403 * Y manejan lecturas de archivos especiales. 

23404 * 

23405 * Los puntos de entrada a este archivo son 

23406 * do_read: ejec. llamada al sistema READ invocando read_write 

23407 * read write: realizar trabajo real de READ y WRITE 

23408 * read_map: dado un nodo-i y pos en arch, buscar su núm de zona 

23409 * rd_indir: leer entrada en un bloque de indirección 

23410 * read_ahead: encargarse de la lectura adelantada de bloques 

23411 */ 

23412 

23413 #include "fs.h" 

23414 #include <fcntl.h> 

23415 #include <minix/com.h> 

23416 #include "buf.h" 

23417 #include "file.h" 

23418 #include "íproc.h" 

23419 #include "inode.h" 

23420 #include "param.h" 

23421 #include "super.h" 

23422 

23423 #defíne FDMASK 077 /* máx. descrip de archivo es 63 */ 

23424 

23425 PRIVATE message umessj /* mensaje p/pedir a SYSTASK copia usuario */ 

23426 

23427 FORWARD PROTOTYPE( int rw_chunk, (struct inode *rip, off_t position, 

23428 unsigned off, int chunk, unsigned left, int rw_flag, 

23429 char *buff, int seg, int usr) ); 

23430 

23431 /♦================================ = ========================== == 

23432 * do_read * 

23433 *=================================================== 

23434 PUBLIC int do_read() 

23435 { 

23436 retum(read_write(READING)); 

23437 } 

23440 /♦= = === = ========== = == = ==== ===== === = === = ===== = === ==== 

23441 * read_write * 

23442 ♦= == ==== ===== ====== === === === = === == == 

23443 PUBLIC int read_write(rw_flag) 

23444 int rw_flag; /* READING o WRITING */ 

23445 { 

23446 /* Ejecutar llamada read(fd, buffer, nbytes) o write(fd, buffer, nbytes). */ 

23447 

23448 register struct inode *rip; 

23449 register struct filp *f; 

23450 off_t bytesjeft, f_size, position; 

23451 unsigned int off, cum_io; 

23452 int op, oflags, r, chunk, usr, seg, block_spec, char_spec; 

23453 int regular, partial_pipe = 0, partial_cnt = 0; 

23454 dev_t dev; 
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23455 

23456 

23457 

23458 

23459 

23460 

23461 

23462 

23463 

23464 

23465 

23466 

23467 

23468 

23469 

23470 

23471 

23472 

23473 

23474 

23475 

23476 

23477 

23478 

23479 

23480 

23481 

23482 

23483 

23484 

23485 

23486 

23487 

23488 

23489 

23490 

23491 

23492 

23493 

23494 

23495 

23496 

23497 

23498 

23499 

23500 

23501 

23502 

23503 

23504 

23505 

23506 

23507 

23508 

23509 

23510 

23511 

23512 

23513 

23514 


modet modeword; 
struct filp *wf; 

/* MM carga segmentos poniendo cosas raras en 10 bits altos de 'fd'. */ 
if (who = MMPROCNR && (fd & (-BYTE))) { 
usr = (fd » 8) & BYTE; 

seg.= (fd » 6) & 03; 

fd &= FDMASK; 

} else { 

usr = who; 
seg = D; 

} 

/* Si descriptor de archivo válido, obtener nodo-i, tamaño y modo. */ 
if (nbytes < 0) retum(EINVAL); 
if ((f = get_filp(fd)) == NIL_FILP) retum(err_code); 
if (((f->filp_mode) & (rw_flag = READING ? R BIT : W BIT)) = 0) { 
retum(f->filp_mode == FILP CLOSED ? EIO : EBADF); 

} 

if (nbytes = 0) retum(O); /* así archs esp de cars no tienen q/probar 0*/ 

position = f->filp_pos; 

if (position > MAX FILE POS) retum(EINVAL); 

if (position + nbytes < position) retum(EINVAL); 1* desbordo sin signo *1 
oflags = f->filp_flags; 
rip = f->filp_ino; 
fsize = rip->i_size; 
r = OK; 

if (rip->i_pipe = I PIPE) { 

/* fpfp->fp_cum_io_partial no es 0 sólo al efectuar lecturas parciales */ 
cum_io = fp->fp_cum_io_partial; 

} else { 

} CUm “° 

op = (rw_flag = READING ? DEV READ : DEV WRITE); 
mode word = rip->i_mode & I TYPE; 

regular = modeword = IREGULAR 11 modeword = INAMEDPIPE; 

char spec = (mode word = I CHAR SPECIAL ? 1 : 0); 
block spec = (mode_word = I BLOCK SPECIAL ? 1 : 0); 
if (block spec) fsize = LONGMAX; 

rdwt_err = OK; /* poner en EIO si ocurre error de disco */ 

/* Verificar si archivos especiales por caracteres. */ 
if (char_spec) { 

dev = (dev t) rip->i zone[0]; 

r = dev_io(op, oflags & Ó_NONBLOCK, dev, position, nbytes, who,buffer); 
if (r >= 0) { 

position += r; 
r = OK; 

} 

} else { 

if (rw_flag = WRITING && block spec == 0) { 

/* Anticipar si el archivo crecerá demasiado. */ 

if (position > rip->i_sp->s_max_size -nbytes) retum(EFBIG); 

/* Verificar bandera O APPEND. */ 
if (oflags & O APPEND) position = f size; 

/* Borrar la zona que contiene EOF actual si se va a crear 


/* descartar bits de usuario y segm */ 
/* caso normal */ 



EL CÓDIGO FUENTE DE MINIX 


Archivo: src/fs/read.c 


845 


23515 

23516 

23517 

23518 

23519 

23520 

23521 

23522 

23523 

23524 

23525 

23526 

23527 

23528 

23529 

23530 

23531 

23532 

23533 

23534 

23535 

23536 

23537 

23538 

23539 

23540 

23541 

23542 

23543 

23544 

23545 

23546 

23547 

23548 

23549 

23550 

23551 

23552 

23553 

23554 

23555 

23556 

23557 

23558 

23559 

23560 

23561 

23562 

23563 

23564 

23565 

23566 

23567 

23568 

23569 

23570 

23571 

23572 

23573 

23574 


* agujero. Esto es necesario porque todos los bloques 

* no escritos antes del EOF deben leerse como ceros. 

*/ 

if (position > f_size) clear_zone(rip, f_size, 0); 

} 

/* Los conductos son un poco diferentes. Verificar. */ 
if (rip->i_pipe == IPIPE) { 

r = PiPe_CheCk(rip,rw_flag,OflagS,nbytes,position,&partial cnt); 
if (r <= 0) retum(r); 

} 

if (partial_cnt > 0) partial_pipe = 1; 

/* Dividir transferencia en trozos que no abarquen dos bloques. */ 
while (nbytes != 0) { 

off = (unsigned int) (position % BLOCK_SIZE);/* disto en blq*/ 
if (partial_pipe) { /* sólo conductos */ 

chunk = MIN(partial_cnt, BLOCKSIZE -off); 

chunk = MIN(nbytes, BLOCK SIZE -off); 
if (chunk < 0) chunk = BLOCK SIZE -off; 

if (rw_flag == READING) { 

bytes_left = f_size -position; 

if (position >= f size) break; /* rebasamos EOF */ 

if (chunk > bytes_left) chunk = (int) bytes_left; 

} 

/* Leer o escribir 'chunk' bytes. */ 

r = rw_chunk(rip, position, off, chunk, (unsigned) nbytes, 
rw_flag, buffer, seg, usr); 

if (r 1= OK) break; /* llegamos a EOF */ 

if (rdwt_err < 0) break; 

/* Actualizar contadores y apuntadores. */ 
buffer += chunk; /* dirección buffer usuario */ 

nbytes -= chunk; /* bytes aún por leer */ 

cum_io += chunk; /* bytes ya leídos */ 

position += chunk; /* posición en archivo */ 

if (partial_pipe) { 

partial_cnt -= chunk; 
if (partial_cnt <= 0) break; 



/* Al escribir, actualizar el tamaño de archivo y el tiempo de acceso. */ 
if (rw_flag = WRITING) { 

if (regular 11 mode_word = I_DIRECTORY) { 
if (position > f_size) rip->i_size = position; 

} 

} else { 

if (rip->i_pipe = IPIPE && position >= rip->i_size) { 

/* Restablecer apuntadores del conducto. */ 
rip->i_size = 0; /* ya no hay datos */ 

position = 0; /* restab. lector(es) */ 

if ( (wf = find_filp(rip, W BIT» != NIL FILP) wf->filp_pos =0; 

} 
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23575 } 

23576 f->filp_pos = position; 

23577 

23578 /* Ver si se requiere lectura adelantada; si sí, prepararla. */ 

23579 if (rw_flag = READING && rip->i_seek = NOSEEK && position % BLOCK_SIZE= 0 

23580 && (regular 11 mode_word = I DIRECTORV» { 

23581 rdahed_inode = rip; 

23582 rdahedpos = position; 

23583 } 

23584 rip->i_seek = NOSEEK; 

23585 

23586 if(rdwt_err l=OK)r = rdwt_err; /* verif. error de disco */ 

23587 if (rdwt err = ENDOFFILE) r = OK; 

23588 if (r = OK) { 

23589 if (rw_flag == READING) rip->i_update 1= ATIME; 

23590 if (rw_flag == WRITING) rip->i_update 1= CTIME IMTIME; 

23591 rip->i_dirt = DIRTV; /* nodo-i ya está sucio */ 

23592 if (partial_pipe) { 

23593 partial_pipe = 0; 

23594 /* escritura parcial en conducto con */ 

23595 /* 0_N0NBL0CK, devolver cuenta de escritura */ 

23596 if (1 (oflags & O NONBLOCR» { 

23597 fp->fp_cum_io_partial = cum_io; 

23598 suspend(XPIPE); /* escrito parcial en conducto con */ 

23599 retum(O); /* nbyte > PIPE SIZE -no atómica */ 

23600 } 

23601 } 

23602 fp->fp_cum_io_partial = 0; 

23603 retum(cum_io); 

23604 } else { 

23605 retum(r); 

23606 } 

23607 } 

23610/*= = = == == = = = = = === = = == = = = = = = = === == = = = = = = == = === === = = == 


23611 * 

23612 *======= 

23613 PRIVATE int 

23614 

23615 

23616 

23617 
23618’ 

23619 

23620 


rw_chunk * 

rw_chunk(rip, position, off, chunk, leñ, rw_flag, buff, seg, usr) 

register struct inode *rip; /* apunt a nodo-i de arch por leer/escr */ 

off_t position; /* posic en arch por leer o escribir */ 

unsigned off; /* distancia en bloque actual */ 

int chunk; /* # bytes por leer o escribir */ 

unsigned leñ; /* máx bytes deseados después de pos */ 

int rwjlag; /* READING o WRITING */ 

char *buff; /* dir virtual del buffer de usuario */ 


23621 int seg; /* segmento T o D en espacio usuario */ 

23622 int usr; /* cuál proceso de usuario */ 

23623 { 

23624 /* Leer o escribir (parte de) un bloque. */ 

23625 


23626 register struct buf *bp; 

23627 register int r; 

23628 int n, block_spec; 

23629 block t b; 


23630 dev_t dev; 


23631 


23632 block spec = (rip->i_mode & I TVPE) = I BLOCK SPECIAL; 

23633 if (block_spec) { 

23634 b = position/BLOCKSIZE; 
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23635 dev = (dev_t) rip->i_zone[0]; 

23636 } else { 

23637 b = read_map(rip, position); 

23638 ctev = rip->i_dev; 

23639 } 

23640 

23641 if (!block_spec && b = NO_BLOCK) { 

23642 if (rw_flag == READING) { 

23643 /* Leer de bloque inexistente. Debe leer sólo ceros.*/ 

23644 bp = get_block(NO_DEV, NO_BLOCK, NORMAL). /* obt buffer */ 

23645 zero_block(bp); 

23646 } else { 

23647 /* Escribir en bloque inexis. Crear e ingresar en nodo-i. */ 

23648 if ((bp= new_block(rip, position)) == NIL_BUF)retum(err_code); 

23649 } 

23650 } else if (rw_flag = READING) { 

23651 /* Leer y leer adelantado si conviene. */ 

23652 bp = rahead(rip, b, position, leñ); 

23653 } else { 

23654 /* Normalmente un bloque existente que se sobreescribirá 

23655 * parcialmente primero se lee, pero no hay que leer un bloque lleno. 

23656 * Si ya está en caché, adquirirlo; si no, adq. buffer libre. 

23657 */ 

23658 n = (chunk = BLOCKSIZE ? NOREAD : NORMAL); 

23659 if (¡block spec && ofif= 0 && position >= rip->i_size) n = NO READ; 

23660 bp = get_block(dev, b, n); 

23661 } 

23662 

23663 /* En todos los casos, bp apunta ahora a un buffer válido. */ 

23664 if (rw_flag = WRITING && chunk != BLOCK SIZE && ¡block spec && 

23665 position >= rip->i_size && off = 0) { 

23666 zero_block(bp); 

23667 } 

23668 if (rw_flag = READING) { 

23669 /* Copiar un trozo del buffer de bloques al espacio de usuario. */ 

23670 r = sys_copy(FS_PROC_NR, D, (phys bytes) (bp->b_data+off); 

23671 usr, seg, (phys_bytes) buff, 

23672 (phys_bytes) chunk); 

23673 } else { 

23674 /* Copiar un trozo del espacio de usuario al buffer de bloques. */ 

23675 r = sys_copy(usr, seg, (phys_bytes) buff, 

23676 FSPROCNR, D, (phys_bytes) (bp->b_data+off); 

23677 (phys_bytes) chunk); 

23678 bp->b_dirt = DIRTY; 

23679 } 

23680 n = (off + chunk = BLOCK SIZE ? FULL DATA BLOCK : PARTIAL DATA BLOCK); 

23681 put_block(bp, n); 

23682 retum(r); 

23683 } 

23686 /*= ==== == = == = ===== = == = = == = == ==== == = == = = ===== === 

23687 * read_map * 

23688 *===== === === === = ====== = ========= = = = = = 

23689 PUBLIC block t read_map(rip, position) 

23690 register struct inode *rip; /* apunt a nodo del cual mapear */ 

23691 off_t position; /* pos en arch cuyo blq se desea */ 

23692 { 

23693 /* Dado un nodo-i y una posición dentro del arch corresp, encontrar 

23694 * el núm de bloque (no de zona) en el que está la posición y devolverlo. 
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23695 */ 

23696 

23697 register struct buf *bp; 

23698 register zone_t Z; 

23699 int scale, boff, dzones, nr_indirects, índex, zind, ex; 

23700 block_t b; 

23701 long excess, zone, block_pos; 

23702 

23703 scale = rip->i_sp->s_log_zone_size; /* p/conversión bloque-zona */ 

23704 block_pos = position/BLOCK_SIZE; /* # bloque relativo en arch */ 

23705 zone = block_pos » scalej /* zona de la posición */ 

23706 boff = (int) (block_pos-(zone « scale) )¡/*# bloque reí. en zona */ 

23707 dzones = rip->i_ndzones; 

23708 nr_indirects = rip->i_nindirs; 

23709 

23710 /* ¿Se encuentra ’position' en el nodo-i mismo? */ 

23711 if (zone < dzones) { 

23712 zind = (int) zone; /* indice debe ser un int */ 

23713 z = rip->i_zone[zind]; 

23714 if (z = NOZONE) retum(NO_BLOCK); 

23715 b = ((block_t) z « scale) + boff; 

23716 retum(b); 

23717 } 

23718 

23719 /* No está en nodo-i, así que debe ser indirec. sencilla o doble. */ 

23720 excess = zone -dzones; /* las. Vx_NR_DZONES no cuentan */ 

23721 

23722 if (excess < nr_indirects) { 

23723 /* ’position' puede hallarse vía bloque indirec. sencilla. */ 

23724 z = rip->i_zone[dzones]; 

23725 } else { 

23726 /* ’position' puede hallarse vía bloque indirec. doble. */ 

23727 if ( (z = rip->i_zone[dzones+l ]) = NO_ZONE) retum(NO_BLOCK)j 

23728 excess -= nr_indirectsj /* indir. sene, no cuenta*/ 

23729 b = (block_t) z « scale; 

23730 bp = get_block(rip->i_dev, b, NORMAL); /* obt. bloque doble indir. */ 

23731 índex = (int) (excess/nr_indirects); 

23732 z = rd_indir(bp, índex); /* z = zona p/sencilla*/ 

23733 put_block(bp, INDIRECTBLOCK); /* liberar blq doble indir. */ 

23734 excess = excess % nr_indirects; /* índice en blq indir sene. */ 

23735 } 

23736 

23737 /* ’z' es núm zona p/bloque indirec. sencillaj 'excess' es índice en él. */ 

23738 if (z == NO ZONE) retum(NO_BLOCK); 

23739 b = (block_t) z« scale; /* b es # blq p/ind sene */ 

23740 bp = get_block(rip->i_dev, b, NORMAL); /* obt bloque indir sene */ 

23741 ex = (int) excess; /* necesitamos un entero */ 

23742 z = rd_indir(bp, ex); /* obt blq al que apunta */ 

23743 put_block(bp, INDIRECT BLOCK); /* soltar blq indir sene */ 

23744 if (z == NO ZONE) retum(NO_BLOCK); 

23745 b = ((block_t) z « scale) + boff; 

23746 retum(b); 

23747 } 

23750 /*= = = = = == = = === = ===== = === === === === === = == = = === === == === = = = = 

23751 * rd_indir 

23752 *=================================== = ======== = ======== 

23753 PUBLIC zone_t rd_indir(bp, Índex) 

23754 struct buf *bpj /* apunto a bloque de indirección */ 
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23755 int índex; /* índice en *bp */ 

23756 { 

23757 /* Dado un apuntador a un bloque de indirección, leer una entrada. 

23758 * Se hace una rutina aparte porque hay cuatro casos: 

23759 * VI (IBM Y 68000) Y V2 (IBM Y 68000). 

23760 */ 

23761 

23762 struct super_block *sp; 

23763 zone_t zone; /* zonas v2 son long s (shorts en VI) */ 

23764 

23765 sp = get_super(bp->b_dev); /* neces. superbloque p/saber tipo FS */ 

23766 

23767 /* leer una zona de un bloque de indirección */ 

23768 if(sp->s_version== VI) 


23769 

23770 

else Z ° ne = 

= (zone_t) conv2(sp->s_nat 

ive, (int) bp->b_' 

M_ind[index]); 

23771 

zone = 

= (zone_t) conv4(sp->s_nat 

ive, (long) bp->b_v2_i 

ndjindex]); 


23772 

23773 if (zone != NO_ZONE && 

23774 (zone < (zone_t) sp->s_firstdatazone 11 zone >= sp->s_zones» { 

23775 printf(" 1 Ilegal zone number %ld in indirect block, índex %d\n", 

23776 (long) zone, Índex); 

23777 panic("check file system", NO_NUM); 

23778 } 

23779 retum(zone); 

23780 } 

23783/*=== = = = == = = === === = = == == = = = = == = == = === = = = === = = = = = == ==* 

23784 * read_ahead * 

23785*==== = ========= = == = = = === = === = = = ==== = === == ===== = === = ====*/ 

23786 PUBLIC voidread_ahead() 

23787 { 

23788 /* Leer un bloque y colocarlo en taché antes de que se necesite. */ 

23789 

23790 register struct inode *rip; 

23791 struct buf *bp; 

23792 blockj b; 

23793 

23794 rip = rdahed_inode; /* apunt a nodo-i desde donde leer */ 

23795 rdahed_inode = NI L_lNODE; /* desactivar lectura adelantada */ 

23796 if ( (b = read_map(rip, rdahedpos» = NO_BLOCK) retum; /* en EOF */ 

23797 bp = rahead(rip,b, rdahedpos, BLOCK_SlZE); 

23798 put_block(bp, PART1AL DATA BLOCK); 

23799 } 

23802/*====================== = ======= === ======= = ==========* 

23803 * rahead * 

23804*=== . === ^^- -- ======= ^ - ..., == = = = ==:= = = = ==:=== = = = = = = == = = = = = = =♦/ 

23805 PUBLIC struct buf *rahead(rip, baseblock, position, bytes_ahead) 

23806 register struct inode *rip; /* apunt a nodo de arch por leer */ 

23807 block_t baseblock; /* bloque en posición actual */ 

23808 off_t position; /* posición en el archivo */ 

23809 unsigned bytes_ahead; /* bytes después pos piusa inmediato */ 

23810 { 

23811 /* Traer un bloque del taché o dispositivo. Si se requiere lectura física, 

23812 * preobtener tantos bloques más como sea cómodo. Esto suele abarcar 

23813 * bytes_ahead y es al menos BL0CKS_M1N1MUM. El controlador 

23814 * puede decidir que es mejor dejar de leer en una frontera de cilindro 
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23815 * (o después de un error). Rw_scattered() pone una bandera opcional 

23816 * en todas las lecturas para permitir esto. 

23817 */ 

23818 

23819 /* Número mínimo de bloques que preobtener. */ 

23820 # define BLOCKS_MINIMUM (NRBUFS < 50 ? 18 : 32) 

23821 

23822 int bloCk_spec, scale, read_q_Size; 

23823 unsigned int blocks_ahead, fragment; 

23 824 block_t bloCk, blocksjeft; 

23825 off t indl_pos; 

23826 dev_t dev; 

23 827 slruct buf *bp; 

23828 static struct buf *read_q[NR_BUFS]; 

23829 

23830 blOck spec = (rip->i_mode & ITYPE) = IBLOCKSPECIAL; 

23831 if (block_spec) { 

23832 dev = (dev_t) rip->i_zone[0]; 

23833 } else { 

23834 dev = rip->i_dev; 

23835 } 

23836 

23837 block = baseblock; 

23838 bp = get_block(dev, block, PREFETCH). 

23839 if (bP->b_dev != NO_DEV) retum(bp); 

23840 

23841 /* La mejor estimación el núm de bloques que preobtener: Muchos. 

23842 * Es imposible saber cómo es el dispositivo, así que ni tratamos 

23843 * de adivinar su geometría; lo dejamos al controlador. 

23844 * 

23845 * El controlador de disquete puede leer toda una pista sin retardo rotacional, 

23846 * Y evita leer pistas parciales si puede, así que es perfecto darle suficientes 

23847 * buffers para leer 2 pistas. (Dos, porque algunos tipos de disquetes tienen 

23848 * núm impar de sectores por pista, así que un bloque puede abarcar pistas.) 

23849 * 

23850 * Los controladores de disco no tratan de ser inteligentes. Con los discos 

23851 * actuales es imposible saber qué geometría tienenj es mejor leer lo más 

23852 * que se pueda. Con Suerte el caché de la unidad da algo de tiempo para 

23853 * iniciar la siguiente lectura. 

23854* 

23855 * Esta solución es casi un hack, sólo lee bloques de la Posición actual 

23856 * en el archivo esperando poder encontrar más del archivo. Una mejor 

23857 * solución debe examinar los apuntadores de zona y bloques de indirección 

23858 * ya disponibles (ipero no invocar read_map!). 

23859 */ 

23860 

23861 fragment = Position % BLOCKSIZE; 

23862 Position -= fragment; 

23863 bytes_ahead += fragment; 

23864 

23865 blocks_ahead = (bytes_ahead + BLOCK SIZE -1) / BLOCK SIZE ¡ 

23866 

23867 if (block_spec && rip->i_size = 0) { 

23868 blocksjeft = NR_IOREOS; 

23869 } else { 

23870 blocksjeft = (rip->i_size -Position + BLOCK SIZE -1) / BLOCK SIZE; 

23871 

23872 /* Ir por el primer bloque de indirección si estamos cerca. */ 

23873 if (!bloCk_spec) { 

23874 scale = rip->i_sP->SJog_zone_size; 
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23875 

23876 

23877 

23878 

23879 

23880 

23881 

23882 

23883 

23884 

23885 

23886 

23887 

23888 

23889 

23890 

23891 

23892 

23893 

23894 

23895 

23896 

23897 

23898 

23899 

23900 

23901 

23902 

23903 

23904 

23905 

23906 

23907 

23908 

23909 

23910 

23911 

23912 

23913 

23914 

23915 


indl_pos = (off t) rip->i_ndzones * (BLOCK SIZE « scale); 
if (position <= indl_pos && rip->i_size > indl_pos) { 
blocks_ahead++; 
blocks_leñ++; 

} 

} 

} 


/* No más que la máxima solicitud. */ 

if (blocks_ahead > NRIOREQS) blocks_ahead = NRIOREQS; 

/* Leer al menos el núm mínimo de bloques, pero no después de búsqueda. */ 
if (blocks_ahead < BLOCKS_MINIMUM && ríp->í_seek = NO SEEK) 
blocks_ahead = BLOCKS_MINIMUM; 

/* No se puede rebasar el fin de archivo. */ 
if (blocks_ahead > blocks_left) blocks_ahead = blocks_left; 

read_q_size = 0; 

/* Adquirir buffers de bloques. */ 

for0;){ 

read_q[read_q_size++] = bp; 

if (—blocks_ahead = 0) break; 

1 * No arruinar el caché, dejar 4 libres. */ 
if (bufs_in_use >= NRBUFS -4) break; 

block++; 

bp = get_block(dev, block, PREFETCH); 
if (bp->b_dev !=NO_DEV) { 

/* iEpa! Bloque ya en caché, salirse. */ 
put_block(bp, FULLDATABLOCK); 

} 

} 

rw_scattered(dev, read q, read_q_size, READING); 
retum(get_block(dev, baseblock, NORMAL)); 

} 


src/fs/write.c 


24000 /* Este archivo es la contraparte de "read.c". Contiene el código 

24001 * para escribir que no está contenido en read_write(). 

24002 * 

24003 * Los puntos de entrada a este archivo son 

24004 * do_wríte: invocar read_wríte p/ejec llamada al sistema WRITE 

24005 * clear_zone: borrar una zona en medía de un archivo 

24006 * new_block: adquirir un nuevo bloque 

24007 */ 

24008 

24009 #include "fs.h" 
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24010 

#include <string.h> 


24011 

#include "buf.h" 


24012 

#include "file.h" 


24013 

#include "fproc.h" 


24014 

#include "inode.h" 


24015 

#include "super.h" 24016 


24017 

FORWARD _PROTOTYPE( int write map, (struct inode *rip, offt position, 


24018 

zone_t new_zone) 

); 

24019 



24020 

FORWARD _PROTOTYPE( void wr indir, (stmct buf *bp, int índex, zone_t z 

one)); 24021 

24023 * 

do_write 

* .... 

24025 

PUBLIC int do write() 


24026 

{ 


24027 

/* Ejecutar la llamada al sistema write(fd, buffer, nbytes). */ 


24028 



24029 

retum(read write(WRITING»; 


24030 

} 


24034 * 
24035*= 

writemap 

==========*/ 


24036 PRIVATE int write_map(rip, position, new_zone) 

24037 register struct inode *rip; /* apunt a nodo-i por modificar */ 

24038 offt positionj /* dirección archivo por mapear */ 

24039 zone_t new_zone; /* núm zona por insertar */ 

24040 { 

24041 /* Escribir una nueva zona en un nodo-i. */ 

24042 int scale, ind_ex, new_ind, new_dbl, zones, nr_indirects, single, zindex, ex; 

24043 zone_t z, zl j 

24044 register block_t b; 

24045 long excess, zone; 

24046 struct buf*bp; 

24047 

24048 rip->i_dirt = DIRTY; /* el nodo-i se modificará */ 

24049 bp = NIL_BUF; 

24050 scale = rip->i_sp->s_log_zone_size; /* p/conversión zona-bloque */ 

24051 zone = (position/BLOCK SIZE) » scalej /*# zona reí por insertar */ 

24052 zones = rip->i_ndzones; /* # zonas directas en el nodo-i */ 

24053 nr_indirects = rip->i_nindirs;/* # zonas indirectas p/blq indir */ 

24054 

24055 /* ¿Se encuentra 'position' en el nodo-i mismo? */ 

24056 if (zone < zones) { 

24057 zindex = (int) zone; /* necesitamos un entero aquí */ 

24058 rip->i_zone[zindex] = new_zone; 

24059 retum(OK); 

24060 } 

24061 

24062 /* No está en el nodo-i; debe ser indirec sencilla o doble. */ 

24063 excess = zone -zones; /* las Vx_NR_DZONES no cuentan */ 

24064 new_ind = FALSE; 

24065 new_dbl = FALSE; 

24066 

24067 if (excess < nr_indirects) { 

24068 /* 'position' puede encontrarse vía bloque indirección sencilla. */ 

24069 zl = rip->i_zone[zones]; /* zona indirec sencilla */ 
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24070 single = TRUE; 

24071 } else { 

24072 7 * ’position' puede encontrarse vía bloque doble indirección. *7 

24073 if ( (z = rip->i_zone[zones+l ]) = NO_ZONE) { 

24074 7 * Crear el bloque de doble indirección. *7 

24075 if ( (z = alloc_zone(rip->i_dev, rip->i_zone[0]» = NO_ZONE) 

24076 retum(err_code); 

24077 rip->i_zone[zones+l ] = Z; 

24078 new_dbl = TRUEj 1 * izar bandera p/después *7 

24079 } 

24080 

24081 7* Como sea, ’z' es núm zona p/bloque doble indirección. *7 

24082 excess -= nr_indirectSj 1 * indirec sencilla no cuenta *7 

24083 ind_ex = (int) (excess 7 nr_indirects); 

24084 excess = excess % nr_indirectS; 

24085 if (ind_ex >= nr_indirects) retum(EFBIG); 

24086 b = (block_t) z « scalej 

24087 bp = get_block(rip->i_dev, b, (new dbl ? NOREAD : NORMAL»; 

24088 if (new_dbl) zero_block(bp); 

24089 zl = rd_indir(bp, ind_ex); 

24090 single = FALSE; 

24091 } 

24092 

24093 7 * zl ahora es zona indirec sencillaj 'excess' es el índice. *7 

24094 if (zl = NO ZONE) { 

24095 7 * Crear bloque indirec y guardar # zona en nodo-i o blq doble indir. *7 

24096 zl = alloc_zone(rip->i_dev, rip->i_zone[0]); 

24097 if (single) 

24098 rip->i_zone[zones] = zl; 7 * actualizar nodo-i *7 

24099 else 

24100 wr_indir(bp, ind_ex, zl); 7* actualizar doble indir *7 

24101 

24102 new ind = TRUE; 

24103 if (bP 1 = NIL BUF) bp->b_dirt = DIRTYj 1 * si doble indir, sucio* 1 

24104 if (z 1 = NO ZONE) { 

24105 put_block(bP, INDIRECT_BLOCK)j 1 * liberar blq doble ind *7 

24106 retum(err_code); 7 * no pudo crear ind sene *7 

24107 } 

24108 } 

24109 put_block(bp, INDIRECT_BLOCK); 1 * liberar bloque doble ind *1 

24110 

24111 1 * zl es el número de zona del bloque de indirección. *1 

24112 b = (block_t) zl « scale; 

24113 bp = get_block(rip->i_dev, b, (new_ind ? NO READ : NORMAL)); 

24114 if (new_ind) zero_block(bp); 

24115 ex = (int) excess; 1 * necesitamos un int aquí *1 

24116 wr_indir(bp, ex, new_zone); 

24117 bp->b_dirt = DIRTY; 

24118 put_block(bp, INDIRECT BLOCK); 

24119 

24120 retum(OK); 

24121 } 

241247*============================================================* 

24125 * wr indir * 

24126 *= = = = = = = = = = = = = = = = = = = = = = = = = = = = =-= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = *7 

24127 PRIVATE void wr indir(bp, índex, zone) 

24128 struct buf *bpj- 7 * apuntador a bloque indirección *7 

24129 int índex; 7 * índice a *bp *7 
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24130 zone_t zone; /* zona por escribir */ 

24131 { 

24132 /* Dado un apuntador a un bloque de indirección, escribir una entrada. */ 

24133 

24134 struct super_block *sp; 

24135 

24136 sp = get~super(bp->b_dev); /* nec superbloque p/hallar tipo de FS */ 

24137 

24138 /* escribir una zona en un bloque de indirección */ 

24139 if (sp->s_version = VI) 

24140 bp->b_vl_ind[index] = (zonel_t) conv2(sp->s_native, (int) zone); 

24141 else 

24142 bp->b_v2_ind[index] = (zone_t) conv4(sp->s_native, (long) zone); 

24143 } 

24146/*===== = === == ===== = ===== = === = === = === = ===== == = = = = ======= === =* 

24147 * clear zone * 

24148*= = = == = == = = === = = == === = = == -=== = = === = = = = = == == == = == ==*/ 

24149 PUBLIC void clear_zone(rip, pos, flag) 

24150 register struct inode *rip; /* nodo-i por borrar */ 

24151 off t pos; /* apunta a bloque por borrar */ 

24152 int-flag; /* 0 si invoc p/read_write, 1 si new_block */ 

24153 { 

24154 /* Poner en ceros una zona, quizá comenzando en la mitad. El parámetro 'pos' 

24155 * da un byte en el 1er bloque por borrar. Clearzone() se invoca desde 

24156 * read_write y new_block(). 

24157 */ 

24158 

24159 register struct buf *bp; 

24160 register block_t b, blo, bhi; 

24161 register off_t next; 

24162 register int scale; 

24163 register zone_t zone_size; 

24164 

24165 /* Si tamaño de bloque y zona iguales, no necesitamos cle'ar_zone(). */ 

24166 scale = rip->i_sp->s_log_zone_size; 

24167 if (scale == 0) retum; 

24168 

24169 zone size = (zone t) BLOCKSIZE « scale; 

24170 if (flag =1) pos = (pos/zone_size) * zone_size; 

24171 next = pos + BLOCK SIZE -1; 

24172 

24173 /* Si 'pos' está en el último bloque de una zona, no borrar la zona. */ 

24174 if (next/zone_size != pos/zone_size) retum; 

24175 if ( (blo = read_map(rip, next» == NO_BLOCK) retum; 

24176 bhi = ( ((blo»scale)+l)« scale) -1; 

24177 

24178 /* Borrar todos los bloques entre 'blo' y 'bhi'. */ 

24179 for (b = blo; b <= bhi; b++) { 

24180 bp = get_block(rip->i_dev, b, NO READ); 

24181 zero_block(bp); 

24182 put_block(bp, FULL DATA BLOCK); 

24183 } 

24184 } 

24187/*= === = === = == = = 

24188 * 

24189*== == == = ==== = ===== == = 


v_block 
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24190 PUBLIC struct buf *new_block(rip, position) 

24191 register struct inode *rip; /* apuntador a nodo-i */ 

24192 off_t position; /* apunt~dor de archivo */ 

24193 { 

24194 /* Adquirir bloque nuevo y devolver apuntador a él. Esto puede requerir 

24195 * asignar una zona completa y después devolver el bloque inicial. 

24196 * Por otro lado, la zona actual podría tener todavía bloques no utilizados. 

24197 */ 

24198 

24199 register struct buf *bp; 

24200 block t b, baseblock; 

24201 zone_t z; 

24202 zone_t zone_size; 

24203 int scale, r; 

24204 struct super_block *sp; 

24205 

24206 /* ¿Está disponible otro bloque en la zona actual? */ 

24207 if ( (b = read_map(rip, position)) = NO_BLOCK) { 

24208 /* Escoger la primera zona si es posible. */ 

24209 /* Perder si el archivo no está vacío pero el primer número de zona 

24210 * es NO_ZONE, que corresponde a una zona llena de ceros. Seria 

24211 * mejor buscar cerca de la última zona real. 

24212 */ 

24213 if (rip->i_zone[0] = NO_ZONE) { 

24214 sp = rip->i_sp; 

24215 z = sP->s_firstdatazone; 

24216 } else { 

24217 z = rip->i_zone[0]; /* buscar cerca de Ira zona */ 

24218 } 

24219 if ( (z = alloc_zone(rip->i_dev, z)) == NO_ZONE) retum(NIL_BUF); 

24220 if ( (r = write_map(rip, position, z)) != OK) { 

24221 ffee_zone(rip->i_dev, z); 

24222 err_code = r; 

24223 return(NIL_BUF); 

24224 } 

24225 

24226 /* Si no escribimos en EOF, borrar zona, por seguridad. */ 

24227 if ( position != rip->i_size) clear_zone(rip, position, 1); 

24228 scale = rip->i_sp->S_log_zone_size; 

24229 base_block = (block_t) z « scale; 

24230 zone_size = (zone_t) BLOCKSIZE « scale; 

24231 b = base_block + (block_t) ((position % zone_Size)/BLOCK_SIZE); 

24232 } 

24233 

24234 bp = get_bloCk(rip->i_dev, b, NO READ); 

24235 zeroblock(bp); 

24236 retum(bp); 

2423 

24249 bp->b_dirt = DIRTY;7 } 

24240 /* = = = = = = = = = = = = == === = = = = = = = = = = === = == == = = == = = = = = = = 

24241 * zeroblock 

24242 *= = = = == = == = ======= = = = = = = = ==== = = === == == === = = = == 

24243 PUBLIC void zero_block(bp) 

24244 register struct buf *bp; /* apunt a buffer por borrar */ 

24245 { 

24246 /* Poner en ceros un bloque. */ 

24247 

24248 memset(bp->b_data, 0, BLOCK SIZE); 
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24250 } 


src/fs/pipe.c 


24300 7 * Este archivo se ocupa de suspender y revivir procesos. Un proceso 

24301 * puede suspenderse porque quiere leer de o escribir en un conducto 

24302 * Y no puede, o porque quiere leer de o escribir en un archivo especial 

24303 * Y no puede. Cuando un proceso no puede continuar se suspende, 

24304 * Y se revive después cuando ya puede continuar. 

24305 * 

24306 * Los puntos de entrada a este archivo son 

24307 * do_pipe: ejecutar llamada al sistema PIPE 

24308 * pipe_check: ver si es factible leer o escribir en conducto 

24309 * suspend: suspender proc que no puede efectuar lectura o escritura 

24310 * release: ver si un proc suspendido puede liberarse y hacerlo 

24311 * revive: marcar un proceso suspendido como ejecutable 

24312 * do_unpause: se envió 1 señal a un procesoj ver si está suspendido 

24313 *7 

24314 

24315 #include "fs.h" 

24316 #include <fcntl.h> 

24317 #include <signal.h> 

24318 #include <minix/boot.h> 

24319 #include <minix/callnr.h> 

24320 #include <minix/com.h> 

24321 #include "dev.h" 

24322 #include "file.h" 

24323 #include "fproc.h" 

24324 #include "inode.h" 

24325 #include "param.h" 

24326 

24327 PAIVATE message mess; 

24328 

243297*============================================= 


24330 * do_pipe * 

24331*==========================================================*7 


24332 PUBLIC int do_pipe() 

24333 { 

24334 7 * Ejecutar la llamada al sistema pipe(fil_des). *7 

24335 

24336 register struct fproc *rfp; 

24337 register struct inode *rip; 

24338 int rj 

24339 struct filp *fil_ptr0, *fil_ptrl; 

24340 int fil_des[2 jj 7 * aquí va la respuesta *7 

24341 

24342 7 * Adquirir dos descriptores de archivo. *7 

24343 rfp = fpj 

24344 if ( (r = get_fd(0, A BIT, &fil_des[0] , &fil_ptr0» 1= OK) retum(r); 

24345 rfp->fp_filp[fil_des[0]] = fiUptrO; 

24346 fil_ptiO->filp_count = 1; 

24347 if ( (r = get_fd(0, W_BIT, &fil_des[l], &fil_ptrl» 1= OK) { 

24348 rfp->fp_filp [fil_des [0] ] = NIL_FILP; 

24349 fil_ptrO->filp_count = 0; 











EL CÓDIGO FUENTE DE MINIX 


Archivo: src/fs/pipe.c 


857 


24350 

24351 

24352 

24353 

24354 

24355 

24356 

24357 

24358 

24359 

24360 

24361 

24362 

24363 

24364 

24365 

24366 

24367 

24368 

24369 

24370 

24371 

24372 

24373 

24374 

24375 

24376 

24377 

24378 

24379 
24382/*= 
24383 * 
24384*= 

24385 

24386 

24387 

24388 

24389 

24390 

24391 


rfp->fp_filp[fil_des[l]] = fil_ptrl ; 
fil_ptrl->filp_count = 1; 

/* Crear el nodo-i en el dispositivo de conducto. */ 
if ( (rip = alloc_inode(PIPE_DEV, IREGULAR)) = 
rfp->fp_filp[fil_des[0]] = NIL_FILP; 
fil_ptrO->filp_count = 0; 
rfp->fp_fdp[fil_des[ 1 ]] = NIL_FILP; 
fil_ptrl->filp_count = 0; 
retum(err_code); 


if (read_only(rip) != OK) panic("pipe device is read only", NO_NUM); 

rip->i_pipe = IPIPE; 
rip->i_mode &= -I REGULAR; 

rip->¡_mode 1= I NAMED PIPE; /* encendido en conductos y FIFOs */ 

fil_ptrO->filp_ino = rip; 

fil_ptrO->filp_flags = ORDONLY; 

dup_inode(rip); /* para doble uso */ 

fil_ptrl->filp_ino = rip; 

fil_ptrl ->filp_flags = OWRONLY; 

rw_inode(rip, WRITING); /* marcar nodo-i como asignado */ 

reply_il = fd_des[0]; 
reply_i2 = fil_des[l]; 

rip->i_update = ATIME 1 CTIME 1 MTIME; 
retum(OK); 

} 


pipe_check 


/* Los conductos son un poco diferentes. Si un proceso lee de un conducto 
cío para el cual aún existe un escritor, suspender el lector. Si el conducto 
:á vacío y no hay escritor, devolver 0 bytes. Si un proceso está escribiendo 
un conducto y nadie está leyendo de él, indicar error de conducto roto. 


PUBLIC int pipe_check(rip, rw_flag, oflags, bytes, position, canwrite) 

register struct inode *rip; /* el nodo-i del conducto */ 
int rw_flag; /* READING o WRITING */ 
int oflagsj /* banderas izadas p/open o fcntl */ 

register int bytes; /* bytes por leer o escr (trozos) */ 
register off_t position; /* posición actual en archivo */ 
int *canwrite; /* retomo: núm bytes escribibles */ 

24392 { 

24393 

24394 * v: 

24395 * e: 

24396 * ei 

24397 

24398 

24399 int r = 0; 

24400 

24401 /* Si está leyendo, ver si el conducto está vacío. */ 

24402 if (rw_flag = READING) { 

24403 if (position >= rip->i_size) { 

24404 /* El proceso está leyendo de un conducto vacío. */ 

24405 if (find_filp(rip, W_BIT) != NIL_FILP) { 

24406 /* Existe un escritor */ 

24407 if (oflags & 0_NONBLOCK) 

24408 r = EAGAIN; 

24409 else 
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24410 

24411 

24412 

24413 

24414 

24415 

24416 

24417 

24418 

24419 

24420 

24421 

24422 

24423 

24424 

24425 

24426 

24427 

24428 

24429 

24430 

24431 

24432 

24433 

24434 

24435 

24436 

24437 

24438 

24439 

24440 

24441 

24442 

24443 

24444 

24445 

24446 

24447 

24448 

24449 

24450 

24451 

24452 

24453 

24454 

24455 

24456 

24457 
24460/*= 
24461 * 
24462*= 


suspend(XPIPE); /* bloquear lector */ 


/* Si necesario, activar escritores dormidos. */ 
if (susp_count > 0) release(rip, WRITE, susp_count); 


/* El proceso está escribiendo en un archivo. */ 

/* if (bytes > PIPESIZE) retum(EFBIG); */ 
if (fmd_filp(rip, R BIT) = NIL FILP) { 

/* Decir a kemel que genere señal SIGPIPE. */ 
sys_kill((int)(fp -¿roe), SIGPIPE); 
retum(EPIPE); 

} 

if (position + bytes > PIPE SIZE) { 

if ((oflags & O NONBLOCK) && bytes < PIPE SIZE) 
retum(EAGAIN); 

else if ((oflags & 0_NONBLOCK) && bytes > PIPE SIZE) { 

if ( (*canwrite = (PIPE SIZE -position)) >0) { 

/* Realizar escritura parcial, hay que despertar al lector. * 
release(rip, READ, susp_count); 
retum(l); 

} else { 

retum(EAGAIN); 

} 

} 

if (bytes >PIPE_SIZE) { 

if ((*canwrite = PIPE SIZE -position) > 0) { 

/* Realizar escritura parcial, hay que despertar 

* al lector, ya que nos suspenderemos en read~.vrite() 

*/ 

release(rip, READ, susp_count); 
retum(l); 


suspend(XPIPE); /* parar escritor —conducto lleno */ 
retum(O); 


/* Se escribe en conducto vacío. Buscar lector suspendido. */ 
if (position = 0) release(rip, READ, susp_count); 


*canwrite ~ 0; 
retum(l); 

} 


24463 PUBLIC void suspend(task) 

24464 int task; /* ¿a quién espera proc? (PIPE = conducto) */ 

24465 { 

24466 /* Tomar medidas p/suspender el procesam. de la llamada actual. 

24467 * Guardar en tabla proc los paráms que se usarán al reanudar. 

24468 * (En realidad, no se usan cuando un proceso está esperando un disp 

24469 * de E/S, pero sí para conductos, y no vale la pena hacer la distinción.) 






EL CÓDIGO FUENTE DE MINIX 


Archivo: src/fs/pipe.c 


859 


/* 20. arg de fcntl() */ 

/* p/lecturas y escrituras */ 

o enviar mensaje respuesta ahora */ 


PUBLIC void release(ip, call_nr, count) 

register struct inode *ip; /* nodo-i del conducto */ 
int call_nr; /* READ, WRITE, OPEN o CREAT */ 
int count; /* núm máx de procs que liberar */ 


24470 */ 

24471 

24472 if (task = XPIPE 11 task = XPOPEN) susp_count++j/* # procs susp en cond*/ 

24473 fp->fp_suspended = SUSPENDED; 

24474 fp->fp_fd = fd « 8 I fs_call; 

24475 fp->fp_task = -task; 

24476 if (task = XLOCK) { 

24477 fp->fp_buffer = (char *) namel; /* 3er. arg de fcntl() */ 

24478 fp->fp_nbytes =requestj 

24479 } else { 

24480 fp->fp_buffer = buffer; 

24481 fj5->fj)_nbytes = nbytes; 

24482 } 

24483 dont_reply = TRUE; 

24484 } 

24487/*=== = = = = === === == === 

24488* 

24489*======= = ======= == 

24490 

24491 

24492 

24493 

24494 

24495 
24496 ! 

24497 ! 

24498 

24499 

24500 

24501 

24502 

24503 

24504 

24505 

24506 

24507 

24508 

24509 

24510 

24511 

24512 

24513 
24516/*= 

24517 * 

24518*= 


/* Ver si cualquier proceso está esperando el conducto cuyo nodo-i está« 
Si hay uno, y estaba tratando de ejecutar la llamada indicada por ’call_nr', 
liberarlo. 


register struct fproc *rp; 

/* Buscar en la tabla de procesos. */ 
for (rp = &íproc[0]; rp < &fproc[NR_PROCS] j rp++) { 
if (rp->fp_suspended = SUSPENDED && 

rp->fp_revived = NOTREVIVING && 
(rp->fp_fd & BYTE) = call_nr && 
rp->fp_filp[rp->fp_fd»8] ->filp_ino = ip) { 
revive((int) (rp -fproc), 0); 

susp_count—; /* saber quién está suspendido */ 

if (-count = 0) retum; 


ip. 


} 


} 


24519 PUBLIC void revive(proc_nr, bytes) 

24520 int proc_nr; /* proceso por revivir */ 

24521 int bytes; /* si espera tarea, cuántos bytes leyó */ 

24522 { 

24523 /* Revivir un proceso que estaba bloqueado. Si un proceso está esperando una tty, 

24524 * ésta es la forma en que finalmente se libera. 

24525 */ 

24526 

24527 register struct fproc *rfp; 

24528 register int task; 

24529 
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24530 

24531 

24532 

24533 

24534 

24535 

24536 

24537 

24538 

24539 

24540 

24541 

24542 

24543 

24544 

24545 

24546 

24547 

24548 

24549 

24550 

24551 

24552 

24553 

24554 
24557/* 
24558 * 
24559*= 

24560 

24561 

24562 

24563 

24564 

24565 

24566 

24567 

24568 

24569 

24570 

24571 

24572 

24573 

24574 

24575 

24576 

24577 

24578 

24579 

24580 

24581 

24582 

24583 

24584 

24585 

24586 

24587 

24588 

24589 


if (proc_nr <011 proc_nr >= NR_PROCS) panic("revive err", proc_nr); 
rfp = &fproc[proc_nr]; 

if (rfp->fp_suspended = NOTSUSPENDED 11 rfp->fp_revived == REVIVING)retum; 

/* La bandera ’reviving' sólo aplica a conductos. Los procesos esperando 

* TTY reciben un mensaje de inmediato. El proceso de revivir es diferente 

* para TTY y conductos. Para TTY, el trabajo ya se hizo; para conductos 

* no: el proceso debe reiniciarse para que pueda volver a intentarlo. 

*/ 

task = -rfp->fp_task; 

if (task = XPIPE 11 task = XLOCK) { 

/* Revivir proceso suspendido por conducto o candado. */ 
rfp->fp_revived = REVIVING; 

reviving++; /* el proc esperaba un conducto o candado */ 

} else { 

rfp->fp_suspended = NOTSUSPENDED; 
if (task == XPOPEN) /* proc bloqueado en open o creat */ 
reply(proc_nr, rfp->fp_fd»8); 

else { 

/* Revivir proceso suspendido por TTY u otro dispositivo. */ 

rfp->fp_Tibytes = bytes; /*fingir q/quiere sólo lo q/hay*/ 

reply(proc_nr, bytes); /* desbloquear proceso */ 

} 

} 


do_unpause 


PUBLIC int do_unpause() 

{ 

/* Se envió una señal a un proceso que está en pausa en el sistema 
* de archivos. Abortar llamada al sistema con el mensaje de error EINTR. 


register struct fproc *rfp; 
int proc_nr, task, fild; 
struct filp *f; 
dev_t dev; 

if (who > MM PROC NR) retum(EPERM); 
proc_nr = pro; 

if (proc_nr <011 proc_nr >= NR_PROCS) panic("unpause err 1", proc_nr); 
rfp = &fproc[proc_nr]; 

if (ríp->fp_suspended = NOT SUSPENDED) retum(OK); 
task = -rfp->fp_task; 

switch(task) { 

case XPIPE: /* proc trata de leer o escribir conducto */ 

case XOPEN: /* proc trata de abrir archivo especial */ 

panic ("fs/do_unpause called with XOPENXn", NO_NUM); 

case XLOCK: /* proc trata de poner candado con FCNTL */ 

case XPOPEN: /* proc trata de abrir un fifo */ 
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24590 

24591 default: /* proc trata hacer E/S disp (p.ej. tty) *1 

24592 fild = (rfp->fp_fd » 8) & 8YTEj/* extraer dése archivo *7 

24593 if (fild <011 fild >= OPEN_MAX)panic("unpause err 2",NO_NUM); 

24594 f = rfp->fp_filp[fild]; 

24595 dev = (dev_t) f->filp_ino->i_zone[0]; 7 * disp esperado *7 

24596 mess.TTY LINE = (dev» MINOR) & BYTE; 

24597 mess.PROCNR = proc_nr; 

24598 

24599 7 * Decir a kemel R o W. Modo es de llamada actual, no open. *7 

24600 mess.COUNT = (rfp->fp_fd & BYTE) == READ ? R BIT : W BIT; 

24601 mess.m_type = CANCEL; 

24602 fp = rfp; 7 * hack ,call_ctty usa fp *7 

24603 (*dmap[(dev» MAJOR) & BYTE] .dmap rw) (task, &mess); 

24604 } 

24605 

24606 rfp->fp_suspended = NOTSUSPENDED; 

24607 reply(proc_nr, EINTR); 7 * señal que interrumpió llamada *7 

24608 retum(OK); 

24609 } 


src/fs/path.c 


24700 7 * Este archivo contiene los procedimientos que buscan nombres de ruta en el sist 

24701 * de directorios y determinan el núm nodo.i correspondiente. 

24702 * 

24703 * Los puntos de entrada a este archivo son 

24704 * eat_path: rutina ’main' del mecan de conversión ruta-a-nodo-i 

24705 * last_dir: encontrar directorio final de una ruta dada 

24706 * advance: analizar un componente de un nombre de ruta 

24707 * search_dir: buscar cadena en directorio y devolver su núm nodo-i 

24708 *7 

24709 

24710#include "fs.h" 

24711 #include <string.h> 

24712 #include <minix/callnr.h> 

24713#include "buf.h" 

24714#include "file.h" 

24715#include "fproc.h" 

24716#include "inode.h" 

24717#include "super.h" 

24718 

24719PUBLIC char dotl[2] = 7 * pique search_dir se salte *7 

24720PUBLIC char dot2[3] = 7* permisos de acceso para, y.. *7 

24721 

24722 FORWARD _PROTOTYPE( char *get_name, (char *old_name, char string [NAME MAX])); 24723 

247247*==========================================================* 

24725 * eat_path * 

24726*============================================================*7 

24727 PUBLIC struct inode *eat_path(path) 

24728 char *path; 7 * nombre de ruta por analizar *7 

24729 { 
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24730 /* Analizar ruta ’path' y colocar su nodo-i en tabla. Si imposible, devolver 

24731 * NIL_INODE como valor de la función y un cód. error en ’err_code'. 

24732 */ 

24733 

24734 register struct inode *ldip, *rip; 

24735 char string[NAME_MAX]; /* poner 1 nombre comp de ruta aquí */ 

24736, ” 

24737 /* Primero abrir la ruta hasta el directorio final. */ 

24738 if ( (ldip = last_dir(path, string)) = NILINODE) 

24739 retum(NIL_INODE); /* imposible abrir dir final */ 

24740 

24741 /* La ruta que sólo es "1" es un caso especial, detectarlo. */ 

24742 if (string[0] = ’\0’) retum(ldip); 

24743 

24744 /* Obtener componente final de la ruta. */ 

24745 rip = advance(ldip, string); 

24746 put_inode(ldip); 

24747 retum(rip); 

24748 } 

24751/*====== = == = = = === = == = = = = == ==== = = = = == = = ===== = = = == = = 

24752 * last_dir 

24753*=========== = ===== == ====== === = = = = == = = = = ==== 

24754 PUBLIC struct inode *last_dir(path, string) 

24755 char *path; /* nombre ruta por analizar */ 

24756 char string[NAME_MAX]; /* componente final se devuelve aquí */ 

24757 { 

24758 /* Dada una ruta ’path' en el espacio de direcciones fs, 

24759 * analizarla hasta el último directorio, traer el nodo-i de ese dir 

24760 * a la tabla de nodos-i y devolver un apuntador al nodo. 

24761 * Además, devolver el componente final de la ruta en 'string'. 

24762 * Si no es posible abrir el último directorio, devolver NIL_INODE, 

24763 * Y dar la razón del fracaso en 'err_code'. 

24764 */ 

24765 

24766 register struct inode *rip; 

24767 register char *new_name; 

24768 register struct inode *new_ip; 

24769 

24770 /* ¿Ruta absoluta o relativa? Inicializar 'rip' según esto. */ 

24771 rip = (*path = T ? fp->fp_rootdir : fp->fp_workdir)¡ 

24772 

24773 /* Si el dir se eliminó o la ruta está vacía, devolver ENOENT. */ 

24774 if (rip->i_nlinks = 011 *path = ’\0’) { 

24775 err_code = ENOENT; 

24776 retum(NIL_INODE); 

24777 } 

24778 

24779 dup_inode(rip); /* se devolverá nodo-i con put_inode */ 

24780 

24781 /* Examinar la ruta componente por componente. */ 

24782 while (TRUE) { 

24783 /* Extraer un componente. */ 

24784 if ( (new_name = get_name(path, string)) == (char*) 0) { 

24785 put_inode(rip); /* ruta errónea en esp usuario */ 

24786 retum(NIL_INODE); 

24787 } 

24788 if (*new_name = ’\0’) 

24789 if ( (rip->i_mode & I TVPE) -I DIRECTORV) 
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24790 retum(rip); /* salida normal */ 

24791 else { 

24792 /* último arch de prefijo de ruta no es directorio */ 

24793 put_inode(rip); 

24794 errcode = ENOTDIRj 

24795 retum(NIL_INODE)¡ 

24796 } 

24797 

24798 /* Hay más ruta. Seguir analizando. */ 

24799 new ip = advanCe(rip, string); 

24800 put=inode(rip); /* rip obsoleto o no aplica */ 

24801 if (new_ip = NIL INODE) retum(NIL_INODE); 

24802 

24803 /* Exito en llamada advance(). Traer siguiente componente. */ 

24804 path = new_name; 

24805 rip = new_ip; 

24806 } 

24807 } 

24810 /*====================================== = =========== 

24811 * get_name 

24812 * ■ ■ .■ === ^ === = == ^.^ ======= = ======= == ===== = = 

24813 PRIVATE char *get_name(old_name, string) 

24814 char *old_name; /* nombre de ruta p/analizar */ 

24815 char string[NAME_MAX]; /* componente extraído de ’old_name' */ 

24816 { 

24817 /* Dado un apuntador a un nombre de ruta en espacio fs, ’old_name', 

24818 * copiar siguiente componente en 'string' y rellenar con ceros. Se devuelve 

24819 * un apuntador a la parte del nombre aún no analizada. Aproximadamente, 

24820 * ’get_name' = ’old_name' -'string'. 

24821 * 

24822 * Esta rutina sigue la convención estándar de que /usr/ast, /usr//ast, 

24823 * //usr///ast y /usr/ast/ son equivalentes. 

24824 */ 

24825 

24826 register int C; 

24827 register char *np, *mp; 

24828 

24829 np = string; /* ’np' apunta a posic actual */ 

24830 rnp = old_name; /* ’mp' apunta a cadena no analiz */ 

24831 while ( (c = *mp) — 7) mp++; /* saltar diagonales inic */ 

24832 

24833 /* Copiar la ruta no analizada, ’old_name' en arreglo 'string'. */ 

24834 while ( mp < &old_name[PATH_MAX] && c 1= ’/’ && c != ’\0’) { 

24835 if (np < &string[NAME_MAX]) *np++ = C; 

24836 c = *++mp; /* avanzar a siguiente carácter */ 

24837 } 

24838 

24839 /* P/hacer /usr/ast/ equivalente a /usr/ast, saltar diagonales finales. */ 

24840 while (c == ’/’ && rnp < &old_name[PATH_MAX]) c = *++mp; 

24841 

24842 if(np<&string[NAME_MAX]) *np = '\0'; /* Terminar cadena */ 

24843 

24844 if (mp >= &old_name[PATH_MAX]) { 

24845 errcode = ENAMETOOLONG; 

24846 retum«char *) 0); 

24847 } 

24848 retum(mp); 

24849 } 
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24852 / 

24853 ' 

24854 ' 

24855 

24856 

24857 
buscar */ 

24858 

24859 

24860 

24861 

24862 

24863 

24864 

24865 

24866 

24867 

24868 

24869 

24870 

24871 

24872 

24873 

24874 

24875 

24876 

24877 

24878 

24879 

24880 

24881 

24882 
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24885 

24886 
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24890 

24891 
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24893 
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24895 

24896 

24897 

24898 

24899 

24900 

24901 

24902 

24903 

24904 

24905 
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24908 

24909 


Archivo: src/fs/path.c 


EL CODIGO FUENTE DE MINIX 


:t inode *advance(dirp, string) 

struct inode *dirp; /* nodo-i del dir para buscar */ 

char string[NAME_MAX]; /* componente que 


/* Dado un directorio y un componente de una ruta, buscar el componente 
n el directorio, encontrar el nodo-i, abrirlo y devolver un apuntador 
su ranura de nodo-i. Si no se puede, devolver NIL_INODE. 


register struct inode *rip; 
struct inode *rip2; 
register struct super_block *sp; 
int r, inumb; 


dev_t 


t_dev; 


/* Si 'string' está vacía, entregar el mismo nodo-i de inmediato. */ 
if (string[0] = '\0') retum(get_inode(dirp->i_dev, (int) dirp->i_num)); 

/* Detectar NIL INODE. */ 

if (dirp :: NIL INODE) retum(NIL_INODE); 

/* Si 'string' no está en el directorio, indicar error. */ 
if ( (r : search_dir(dirp, string, &numb, LOOK_UP)) !: OK) { 
err_code: r; 

retum(NIL_INODE); 

} 

/* No rebasar directorio raíz actual, a menos que la cadena sea dot2. */ 
if (dirp ==íp->íp_rootdir && strcmp(string, "..") = 0 && string != dot2) 
retum(get_inode(dirp->i_dev, (int) dirp->i_num)); 

/* Se halló el componente en el directorio. Obtener nodo-i. */ 
if ( (rip = get_inode(dirp->i_dev, (int) numb)) = NIL_INODE) 
retum(NIL_INODE); 

if (rip->i_num = ROOTINODE) 

if (dirp->i_num = ROOTINODE) { 
if (string[l] = '.') { 

for (sp = &super_block[l]; sp < &super_block[NR_SUPERS]; sp++){ 
if (sp->s_dev == rip->i_dev) { 

/* Liberar nodo-i raíz. Sustituir por el nodo 
* en que está montado. 

*/ 

put_inode(rip); 

mnt_dev = sp->s_imount->i_dev; 
inumb = (int) sp->s_imount->i_num; 
rip2 = get_inode(mnt_dev, inumb); 
rip = advance(rip2, string); 
put_inode(rip2); 
break; 
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24910 

24911 

24912 

24913 

24914 

24915 

24916 

24917 

24918 

24919 

24920 

24921 

24922 

24923 

24924 

24925 

24926 

24927 

24928 

24929 

24930 
24933/* 
24934 * 
24935*= 
24936 


if (rip = NILINODE) retum(NIL_INODE); 

/* Ver si el nodo-i tiene un sist arch montado. Si sí, cambiar al dir 

* raiz de ese sistema. El superbloque es el enlace entre el nodo-i de 

* montura y el directorio raíz del sistema de archivos montado. 

*/ 

while (rip 1= NIL INODE && rip->i_mount = I MOUNT) { 

/* Sí hay un sistema de archivos montado en el nodo-i. */ 
for (sp = &super_block[0]; sp < &super_block[NR_SUPERS]; sp++) { 
if (sp->s_imount = rip) { 

/* Liberar el nodo-i. Sustituir por el nodo-i raíz 
* del dispositivo montado. 

*/ 

put_inode(rip); 

rip = get_inode(sp->s_dev, ROOTINODE); 
breakj 

} 


retum(rip); 

} 


/* devolver apuntador a componente de nodo-i */ 


search_dir 


PUBLIC int search_dir(ldir_ptr, string, numb, flag) 

24937 register struct inode *ldir_ptr; /* apunt a nodo del dir p/buscar */ 

24938 char string[NAME_MAX]; /* componente que 

buscar */ 

24939 ino_t *numbj /* apunt a número de nodo-i */ 

24940 int flag; /* LOOKUP, ENTER, DELETE o 

ISEMPTY */ 

24941 { 

/* Esta función busca en el dir a cuyo nodo-i ’ldip' apunta: 
si (flag = ENTER) ingresar 'string' en el dir con # nodo-i ’*numb'; 
si (flag — DELETE) eliminar 'string' del directorio; 
si (flag = LOOK_UP) buscar 'string' y devolver # nodo-i en 'numb'; 
si (flag = IS_EMPTY) devolver OK si sólo, y ..en dirj si no, ENOTEMPTY; 


'string' es dotl o dot2, no se verifican permisos de acceso. 


24942 

24943 

24944 

24945 * 

24946 * 

24947 

24948 * 

24949 

24950 

24951 register struct direct *dp; 

24952 register struct buf *bp; 

24953 int i, r, e_hit, t, match; 

24954 mode_t bits; 

24955 offtpOS; 

24956 unsigned new_slots, old_slots; 

24957 block_t b; 

24958 struct super_block *sp; 

24959 int extended = 0; 

24960 

2496~ /* Si 'ldir_ptr' no es un apuntador a nodo-i de dir, error. */ 

24962 if ( (ldir_ptr->i_mode & I TYPE) != I DIRECTORY) retum(ENOTDIR); 

24963 

24964 r = OK; 

24965 

24966 if (flag 


24967 

24968 

24969 


!= IS EMPTY) { 

bits = (flag = LOOK UP ? X BIT: W_BIT IX BIT); 


if (string = dotl 11 string = dot2) { 
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24970 

24971 

24972 

24973 

24974 

24975 

24976 

24977 

24978 

24979 

24980 

24981 

24982 

24983 

24984 

24985 

24986 

24987 

24988 

24989 

24990 

24991 

24992 

24993 

24994 

24995 

24996 

24997 

24998 

24999 

25000 

25001 

25002 

25003 

25004 

25005 

25006 

25007 

25008 

25009 

25010 

25011 

25012 

25013 

25014 

25015 

25016 

25017 

25018 

25019 

25020 

25021 

25022 

25023 

25024 

25025 

25026 

25027 

25028 

25029 


if (flag != LOOK_UP) r = read_only(ldir_ptr); 

/* sólo se requiere un dispositivo escribible. */ 

} 

else r = forbidden(ldir_ptr, bits); /* verif. permisos acceso */ 

} 

if (r != OK) retum(r); 

/* Recorrer el directorio bloque por bloque. */ 

old_slots = (unsigned) (ldir_ptr->i_size/DIR_ENTRY_SIZE); 

new_slots = 0; 

e_hit = FALSE; 

match = 0; /* 1 si concuerda la cadena */ 

for (pos = 0; pos < ldir_ptr->i_size; pos += BLOCK SIZE) { 

b = read_map(ldir_ptr, pos); /* obtener núm bloque */ 

/* Directorios no tienen agujeros, así que ’b' no puede ser NO_BLOCK. */ 

bp = get_block(ldir_ptr->i_dev, b, NORMAL); /* obt bloque dir */ 

/* Buscar en un bloque de directorio. */ 

for (dp = &bp->b_dir[0]; dp < &bp->b_dir[NR_DIR_ENTRIESJ j dp++) { 
if (++new_slots > old_slotS) { /* no hallado, pero cabe */ 
if (flag = ENTER) e_hit = TRUE; 

} 


/* Hay concordancia si se encuentra la cadena. */ 
if (flag != ENTER && dp->d_ino != 0) { 
if (flag = ISEMPTY) { 

/* Si pasa la prueba, dir no vacio. */ 
if (strcmp(dp->d_name, ) != 0 && 

strcmp(dp->d_name, "..") != 0) match = 1; 

} else { 

if (stmcmp(dp->d_name, string, NAME_MAX) = 0) 
match = 1; 

} 

} 

if (match) { 

/* LOOKUP o DELETE halló lo que buscaba. */ 

r = OK; 

if (flag = IS EMPTY) r = ENOTEMPTY; 

else if (flag = DELETE) { 

/* Guardar d_ino p/recuperación. */ 
t = NAME_MAX -sizeof(ino_t); 

*((ino_t *) &dp->d_name[t]) = dp->d_ino; 
dp _> d_ino = 0; /* borrar entrada */ 

bp->b_dirt = DIRTY; 
ldir_ptr->i_update 1= CTIME 1 MTIME; 
ldir_ptr->i_dirt = DIRTY; 

} else { 

sp = ldir_ptr->i_sp; /* 'flag' es LOOK_UP */ 

*numb = conv2(sp->s_native, (int) dp->d_ino); 

} 

put_block(bp, DIRECTORY BLOCK); 
retum(r); 


/* Ver si ranura libre p/beneficio de ENTER. */ 
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25030 if (flag = ENTER && dp->d_ino = 0) { 

25031 e_hit = TRUE; /* hallamos ranura libre */ 

25032 break; 

25033 } 

25034 } 

25035 

25036 1 * Buscamos todo el bloque o ENTER tiene ranura libre. *1 

25037 if (e_hit) break; /* e_hit es 1 si ENTER ejecutable *1 

25038 put_block(bp, DIRECTORYBLOCK); /* si no, seguir buscando */ 

25039 } 

25040 

25041 1 * Ya se buscó en todo el directorio. */ 

25042 if (flag != ENTER) retum(flag = IS_EMPTY ? OK : ENOENT); 

25043 

25044 /* Esta llamada es para ENTER si aún no se ha encontrado una ranura libre, 

25045 * tratar de extender el directorio. 

25046 */ 

25047 if (e_hit = FALSE) { 1 * dir lleno y no hay espacio en últ bloque */ 

25048 new_slots++; 1 * aumentar tamaño dir en 1 entrada *1 

25049 if (new_slots = 0) retum(EFBIG); /* tam dir limit por # ranuras *1 

25050 if ( (bp = new_block(ldir_ptr, ldir_ptr->i_size)) = NIL_BUF) 

25051 retum(err_code); 

25052 dp = &bp->b_dir[0]; 

25053 extended =1; 

25054 } 

25055 

25056 1 * 'bp' ahora apunta a bloque de dir con espacio, 'dp' apunta a ranura. */ 

25057 (void) memset(dp->d_name, 0, (size_t) NAME_MAX); 1 * borrar entrada */ 

25058 for (i = 0; string[i] && i < NAME_MAX; i++) dp->d_name[i] = string[i]; 

25059 sp = ldir_ptr->i_sp; 

25060 dp->d_ino = conv2(sp->s_native, (int) *numb); 

25061 bp->b_dirt = DIRTY; 

25062 put_block(bp, DIRECTORY BLOCK); 

25063 ldir_ptr->i_update 1= CTIME IMTIME; /* marcar mtime p/actualizar */ 

25064 ldir_ptr->i_dirt = DIRTY; 

25065 if (new_slots > old_slots) { 

25066 ldir_ptr->i_size = (off_t) new_slots * DIR ENTRY SIZE; 

25067 1* Enviar cambio a disco si se extendió el directorio. */ 

25068 if (extended) rw_inode(ldir_ptr, WRITING); 

25069 } 

25070 retum(OK); 

25071 } 


src/fs/mount.c 


25100 /* Este archivo ejecuta las llamadas al sistema MOUNT y UMOUNT. 

25101 * 

25102 * Los puntos de entrada a este archivo son 

25103 * do_mount: ejecutar llamada al sistema MOUNT 

25104 * do_umount: ejecutar llamada al sistema UMOUNT 

25105 */ 

25106 

25107 #include "fs.h" 

25108 #include <fcntl.h> 

25109 #include <minix/com.h> 
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25110 #include <sys/stat.h> 

25111 #include "buf.h" 25112 #include "dev.h" 

25113 #include "file.h" 

25114 #include "fproc.h" 25115 #include "inode.h" 25116 #include "param.h" 25117 #include "super:h" 

25118 

25119 PRIVATE message devmess; 

25120 

25121 FORWARD _PROTOTYPE( dev t nametodev, (char *path) ); 

25122 

25123 /♦===== == = === = == = == = ==== == = == ====== ♦ 

25124 * do_mount * 

25125 *== = ========= == ==== = = = = === ===== = = == = = ===== = = = ==== === */ 

25126 PUBLIC int do_mount() 

25127 { 

25128 /* Ejecutar la llamada al sistema mount(name, mfile, rd_only). */ 

25129 

25130 register struct inode *rip, *root_ip; 

25131 struct super_block *xp, *sp; 

25132 devtdev; 

25133 mode_tbits; 

25134 int rdir, mdir; /* TRUE si archivo {rootlmount} es dir */ 

25135 int r, found, maj ar, task; 

25136 

25137 /* S610 el superusuario puede ejecutar MOUNT. */ 

25138 if (!super_user) retum(EPERM); 

25139 

25140 /* Si 'ñame' no es de un archivo especial por bloques, devolver error. */ 

25141 if (fetch_name(name 1, ñame l_length, MI) != OK) return(err_code)j 

25142 if ( (dev = name_to_dev(user_path)) = NO_DEV) retum(err_code); 

25143 

25144 /* Examinar tabla superbloques p/ver si disp ya montado y hallar ranura*/ 

25145 sp = NILSUPER; 

25146 found = FALSE; 

25147 for (xp = &super_block[0] j xp < &super_block[NR_SUPERS]; xp++) { 

25148 if (xp->s_dev = dev) found = TRUE; /* ¿ya está montado? */ 

25149 if (xp->s_dev = NO_DEV) sp = xp; /* regist ranura libre */ 

25150 } 

25151 if (found) retum(EBUSY); /* ya montado */ 

25152 if (sp = NIL_SUPER) retum(ENFILE); /* no superbloque disponible */ 

25153 

25154 dev_mess.m_type = DEV_OPEN; /* distinguir de cerrar */ 

25155 dev_mess.DEVICE = dev; /* tocar el dispositivo. */ 

25156 if (rd_only) devjness.COUNT = R BIT; 

25157 else dev_mess.COUNT = R BITIW BIT; 

25158 

25159 majar = (dev » MAJOR) & BYTEj 

25160 if (major<= 0 11 majar >=max_major) retum(ENODEV); 

25161 task = dmapjmajor] ,dmap_task; /* núm tarea de dispositivo */ 

25162 (*dmap[major] ,dmap_open) (task, &dev_mess); 

25163 if (dev mess.REP STATUS != OK) retum(EINVAL); 

25164 

25165 /* Llenar el superbloque. */ 

25166 sp->s_dev = dev; /* read_super() nec saber cuál disp */ 

25167 r = read_super(sp); 

25168 

25169 /* ¿Se reconoce como sistema de archivos Minix? */ 
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25170 if (r 1= OK) { 

25171 dev_mess.m_type = DEV_CLOSE; 

25172 devmesS.DEVICE = dev; 

25173 (*dmap[major] ,dmap_close) (task, &dev_mess); 

25174 retum(r); 

25175 } 

25176 

25177 /* Ahora obtener el nodo-i del archivo en el que se montará. *1 

25178 if (fetch_name(name2, name2_length, MI) 1= OK) { 

25179 sp->s_dev = NO_DEV; 

25180 dev_mess.m_type = DEV_CLOSE; 

25181 devmesS.DEVICE = dev; 

25182 (*dmap[major] ,dmap_Close) (task, &dev_mess); 

25183 return(err_code); 

25184 } 

25185 if ( (rip = eat_path(user_path)) = NIL_INOOE) { 

25186 sp->s_dev = NO_DEV; 

25187 dev_mess.m_type = DEV_CLOSE; 

25188 devmesS.DEVICE = dev; 

25189 (*dmap[major] ,dmap_close) (task, &dev_mess); 

25190 retum(err_cOde); 

25191 } 

25192 

25193 1 * Podría no estar ocupado. */ 

25194 r = OK; 

25195 if (rip->i_count > 1) r = EBUSY; 

25196 

25197 /* Podría no ser especial. *1 

25198 bits = rip->i_mode & ITYPE; 

25199 if (bits == I BLOCK SPECLAL 11 bits = I_CHAR_SPECIAL) r = ENOTDIR; 

25200 

25201 1 * Obtener nodo-i del sistema de archivos montado. * { 

25202 root_ip = NIL_INODE; 1 * si ’r' no OK, asegurar q/esté definido *1 

25203 if (r = OK) { 

25204 if ( (root_ip = get_inode(dev, ROOT INODE)) == NILINODE) r = err code; 

25205 } 

25206 if (root ip != NIL INODE && rootJp->i_mode == 0) r = EINVALj 

25207 

25208 1 * No puede haber conflicto entre tipos de arch 'rip' y ’root_ip'. *1 

25209 if (r = OK) { 

25210 mdir = ((np->i_mode & I TYPE) = I DIRECTORY); 1 * TRUE si dir */ 

25211 rdir = ((root_ip->i_mode & I TYPE) = I_DIRECTORY)j 

25212 if (!mdir && rdir) r = EISDIR; 

25213 } 

25214 

25215 1 * Si error, devolver superbloque y ambos nodos-ij liberar los mapas. *1 

25216 if (r != OK) { 

25217 put_inode(rip); 

25218 put_inOde(root_ip); 

25219 (Void) do_sync(); 

25220 invalidate(dev); 

25221 

25222 sp->s_dev = NODEV; 

25223 dev_mess.m_type = DEV_CLOSE; 

25224 devmesS.DEVICE = dev; 

25225 (*dmap[major] ,dmap_close) (task, &dev_mess); 

25226 retum(r); 

25227 } 

25228 

25229 1 * Nada más puede salir mal. Montar. *1 
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25230 rip->i_mount = I_MOUNT; /* este bit dice que montado en nodo-i */ 

25231 sp->s_imount = rip; 

25232 sp->s_isup = root_ip; 

25233 sp->s_rd_only = rd_only; 

25234 retum(OK)¡ 

25235 } 

25238/*=================================================== == === = =* 

25239 * do_umount * 

25240*================================================= = ===== = */ 

25241 PU8LIC int do_umount() 

25242 { 

25243 /* Ejecutar la llamada al sistema umount(name). */ 

25244 

25245 register struct inode *rip; 

25246 struct super_block *sp, *spl; 

25247 dev_t dev; 

25248 intcount¡ 

25249 int majar, task; 

25250 

25251 /* Sólo el superusuario puede ejecutar UMOUNT. */ 

25252 if (! super_user) retum(EPERM); 

25253 

25254 /* Si 'ñame' no es de un archivo especial por bloques, devolver error. */ 

25255 if (fetch_name(name, name_length, M3) 1= OK) retum(err_code); 

25256 if ( (dev = name_to_dev(user_path)) = NO_DEV) retum(err_code); 

25257 

25258 /* Ver si el disp montado está ocupado. Sólo debe estar abierto 

25259 * un nodo-i que lo use, el raíz, y ese nodo-i sólo una vez. 

25260 */ 

25261 count = 0; 

25262 for (rip = &inode[0]; rip< &inode[NR_INODES] ¡ rip++) 

25263 if (rip->i_count > 0 && rip->i_dev = dev) count += rip->i_count¡ 

25264 if (count > 1) retum(EBUSY)¡ /* imposible desmontar si ocupado */ 

25265 

25266 /* Encontrar el superbloque. */ 

25267 sp = NILSUPER; 

25268 for (spl = &super_block[0]; spl < &super_block[NR_SUPERS]¡ spl++) { 

25269 if (spl->s_dev = dev) { 

25270 sp = spl; 

25271 break; 

25272 } 

25273 } 

25274 

25275 /* Sincronizar el disco e invalidar el caché. */ 

25276 (void) do_sync(); /* sacar de memoria bloques en caché */ 

25277 invalidate(dev); /* invalidar entradas caché este disp */ 

25278 if (sp = NIL SUPER) retum(EINVAL); 

25279 

25280 majar = (dev» MAJOR) & BYTE; /* núm disp principal */ 

25281 task = dmapjmajor] ,dmap_task¡ /* núm tarea de dispositivo */ 

25282 dev_mess.m_type = DEV_CLOSE; /* distinguir de open */ 

25283 devmess.DEVICE = dev; 

25284 (*dmap[major] ,dmap_close) (task, &dev_mess); 

25285 

25286 /* Terminar de desmontar. */ 

25287 sp->s_imount->i_mount = NO_MOUNT; /* nodo.i vuelve a normal */ 

25288 put_inode(sp->s_imount); /* liberar nodo-i en el que se montó */ 

25289 put_inode(Sp->s_isup); /* liberar nodo-i raíz del fs montado */ 



EL CÓDIGO FUENTE DE MINIX 


Archivo: src/fs/mount.c 


871 


25290 sp->s_imount = NILINODE; 

25291 sp.>s_dev = NO_DEV; 

25292 return(OK); 

25293 } 

25296 /*======-====================== === ============= = ===* 

25297 * nametodev * 

25298 *============================================================*/ 

25299 PRIVATE dev_t name_to_dev(path) 

25300 char *pathj /* apunt a nombre ruta */ 

25301 { 

25302 /* Convertir el arch esp p/bloques ’path' en núm de dispositivo, si ’path' 

25303 * no es arch especial p/bloques, devolver cód. error en ’err_code'. 

25304 */ 

25305 

25306 register struct inode *rip; 

25307 register dev_t dev; 

25308 

25309 /* Si ’path' no puede abrirse, desistir de inmediato. */ 

25310 if ( (rip = eat_path(path)) = NIL INODE) retum(NO_DEV); 

25311 

25312 /* Si ’path' no es archivo especial por bloques, devolver error. */ 

25313 if ( (rip->i_mode & ITVPE) != I BLOCK SPECIAL) { 

25314 err_code = ENOTBLK; 

25315 put_inode(rip); 

25316 retum(NO_DEV); 

25317 } 

25318 

25319 /* Extraer el número de dispositivo. */ 

25320 dev = (dev_t) rip->i_zone[0]; 

25321 put_inode(rip); 

25322 return(dev); 

25323 } 


srC/fs/link.c 


25400 /* Este archivo maneja las llamadas LINK y UNLINK, y también se encarga de 

25401 * liberar la memoria ocupada por un archivo cuando se ejecuta el último UNLINK 

25402 * a un archivo y los bloques deben devolverse a la reserva de bloques libres. 

25403 * 

25404 * Los puntos de entrada a este archivo son 

25405 * do_link: ejecutar llamada al sistema LINK 

25406 * do unlink: ejecutar llamadas a sistemas UNLINK y RMDIR 

25407 * do_rename: ejecutar llamada al sistema RENAME 

25408 * trúncate: liberar todos los bloques asociados a un nodo.i 

25409 */ 

25410 

25411 #include "fs.h" 

25412 #include <sys/stat.h> 

25413 #include <string.h> 

25414 #include <minix/callnr.h> 

25415 #include "buf.h" 

25416 #include "file.h" 

25417 #include "íproc.h" 

25418 #include "inode.h" 

25419 #include "param.h" 
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25420 #include "super.h" 

25421 

25422 #defme SAME 1000 

25423 

25424 FORWARD _PROTOTYPE( int remove_dir, (struct inode *rldirp, struct inode *rip, 

25425 char dir_name[NAME_MAX]) ); 

25426 

25427 FORWARD _PROTOTYPE( int unlink_file, (struct inode *dirp, struct inode *rip, 

25428 char file_name[NAME_MAX]) ); 

25429 

25430 

25431 /♦= ======= === ============== = === = ===== 

25432 * dojink * 

25433 ♦======================================================== 

25434 PUBLIC int do_link() 

25435 { 

25436 /* Ejecutar la llamada al sistema link(namel, name2). */ 

25437 

25438 register struct inode *ip, *rip; 

25439 register int r; 

25440 char string[NAME_MAXlj 

25441 struct inode *new_ip; 

25442 

25443 /* Ver si existe 'ñame' (arChivo al que se vinculará). */ 

25444 if (fetch_name(name 1, ñame 1 _length, M1) 1 = OK) retum(err_code)j 

25445 if ( (rip = eat_path(user_path)) = NIL_INODE) retum(err_code); 

25446 

25447 /* Ver si el archivo ya tiene el máximo de vínculos. */ 

25448 r = OK; 

25449 if ( (rip->i_nlinks & BYTE) >= LINK MAX) r = EMLINK; 

25450 

25451 /* Sólo el superusuario puede vincular a directorios. */ 

25452 if (r = OK) 

25453 if ( (rip->i_mode & I TYPE) = I DIRECTORY && Isuper user) r = EPERM; 

25454 

25455 /* Si error con 'ñame', devolver el nodo-i. */ 

25456 if(r 1= OK) { 

25457 put_inode(rip); 

25458 retum(r); 

25459 } 

25460 

25461 /* ¿Existe el directorio final para 'name2'? */ 

25462 if (fetch_name(name2, name2_length, MI) != OK) { 

25463 put_inode(rip); 

25464 retum(err_code); 

25465 } 

25466 if ( (ip = last_dir(user_path, string)) == NIL_INODE) r = err_code; 

25467 

25468 /* Si ’name2' existe completo (aunque no espacio), hacer r = error. */ 

25469 if (r = OK) { 

25470 if ( (new_ip = advance(ip, string)) == NIL_INODE) { 

25471 r = err_codej 

25472 if (r = ENOENT) r = OK; 

25473 } else { 

25474 put_inode(new_ip); 

25475 r = EEXIST; 

25476 } 

25477 } 

25478 

25479 /* Ver si hay vínculos entre dispositivos. */ 
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25480 if(r = OK) 

25481 if (rip->i_dev != ip->i_dev) r = EXDEV; 

25482 

25483 /* Tratar de vincular. */ 

25484 if (r = OK) 

25485 r = sea,rch_dir(ip, string, &rip->i_num, ENTER)j 

25486 

25487 /* Si se logra, registrar el vínculo. */ 

25488 if (r = OK) { 

25489 rip->i_nlinks++; 

25490 rip->i_update 1= CTIME; 

25491 rip->i_dirt = DIRTY; 

25492 } 

25493 

25494 /* Hecho. Liberar ambos nodos-i. */ 

25495 put_inode(rip); 

25496 put_inode(ip); 

25497 retum(r); 

25498 } 

25501 /♦= - ====================== = = =^.-.^ ========== == ======= 

25502 * do_unlink 

25503 ♦===== === == === == =========== 

25504 PU8LIC int do_unlink() 

25505 { 

25506 /* Ejecutar la llamada al sistema unlink(name) o rmdir(name). El código .de las dos 

25507 * es casi igual, sólo difieren en ciertas pruebas de condiciones. Unlink() puede 

25508 * ser utilizado por el superusuario para hacer cosas peligrosas; rmdir() no. 

25509 */ 

25510 

25511 register struct inode *rip; 

25512 struct inode *rldirp; 

25513 int r; 

25514 char string[NAME_MAX]; 

25515 

25516 /* Obtener el último directorio de la ruta. */ 

25517 if (fetch_name(name, name_length, M3) != OK) retum(err_code); 

25518 if ( (rldirp = last_dir(user_path, string» = NIL_INODE) 

25519 retum(err_code); 

25520 

25521 /* Existe el último directorio. ¿Existe también el archivo? */ 

25522 r = OK; 

25523 if ( (rip = advance(rldirp, string» = NIL_INODE) r = err_code; 

25524 

25525 /* Si error, devolver nodo-i. */ 

25526 if (r != OK) { 

25527 put_inode(rldirp); 

25528 retum(r); 

25529 } 

25530 

25531 /* No quitar un punto de montura. */ 

25532 if (rip->i_num = ROOT INODE) { 

25533 put_inode(rldirp); 

25534 put_inode(rip); 

25535 retum(EBUSY); 

25536 } 

25537 

25538 /* Ahora ver si se permite la llamada. Distinto para unlink() y rmdir(). */ 

25539 if (fs_call = UNLINK) { 
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25540 /* Sólo su puede desvincular directorios, y puede desvincular cualquier dir.*/ 

25541 if ( (rip->i_mode & ITYPE) = I DIRECTORY && Isuper user) r = EPERM; 

25542 

25543 /* No desvinc. arhivo si es raíz de un sistema de archivos montado. */ 

25544 if (rip->i_num == ROOT INODE) r = EBUSY; 

25545 

25546 /* Tratar realmente de desvinc. archivo; falla si padre es modo 0, etc. */ 

25547 if (r == OK) r = unlink_file(rldirp, rip, string); 

25548 

25549 } else { 

25550 r = remove_dir(rldirp, rip, string); /* llamada es RMDIR */ 

25551 } 

25552 

25553 /* Si pudo desvincularse, se hizoj si no, no. */ 

25554 put_inode(rip); 

25555 put_inode(rldirp); 

25556 retum(r); 

25557 } 

25560 /♦== == === = = = —= = == = = = == = == == = == ===== = == = == == = = 

25561 * do_rename * 

25562*======================= === ====== = ===== == =============== 

25563 PUBLIC int do_rename() 

25564 { 

25565 /* Ejecutar la llamada al sistema rename(namel, name2). */ 

25566 

25567 struct inode *old_dirp, *old_ip; /* apunts a dir viejo, nadas arch */ 

25568 struct inode *new_dirp, *new_ip; /* apunts a dir nvo, nadas arch */ 

25569 struct inode *new_superdirp, *next_new_superdirp; 

25570 int r = OK; /* bandera error; inic ninguno */ 

25571 int odir, ndir; /* TRUE si arch {viejolnvo} es dir */ 

25572 int same_pdir; /* TRUE si dirs padres iguales */ 

25573 char old_name[NAME_MAX], new_name[NAME_MAX]; 

25574 ino_t numb; 

25575 intrl; 

25576 

25577 /* Ver si existe ’namel' (arch existente). Obtener nadas de dir y arch. */ 

25578 if (fetch_name(namel, namel_length, MI) != OK) retum(err_code); 

25579 if ( (old_dirp = last_dir(user_path, old_name))=NIL_INODE) retum(err_code); 

25580 

25581 if ( (old_ip = advance(old_dirp, old_name)) = NIL_INODE) r = err_code; 

25582 

25583 /* Ver si existe ’name2'. (arch nuevo). Obtener nadas de dir y arch. */ 

25584 if (fetch_name(name2, name2_length, MI) != OK) r = err_code; 

25585 if ( (new_dirp = last_dir(user_path, new_name)) = NIL_INODE) r = err_codej 

25586 new_ip = advance(new_dirp, new_name); /* no tiene que existir */ 

25587 

25588 if (old ip != NIL INODE) 

25589 odir = «old_ip->i_mode & I TYPE) == I_DIRECTORY)j /* TRUE si dir */ 

25590 

25591 /* Si está bien, tratar de detectar diversos errores posibles. */ 

25592 if (r = OK) { 

25593 same_pdir = (old_dirp = new_dirp); 

25594 

25595 /* El nodo-i viejo no debe ser superdir del nuevo últ dir. */ 

25596 if (odir && ! same_pdir) { 

25597 dup_inode(new_superdirp = new_dirp); 

25598 while (TRUE) { /* puede esperar en ciclo del FS */ 

25599 if (new_superdirp = old_ip) { 
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25600 

25601 

25602 

25603 

25604 

25605 

25606 

25607 

25608 

25609 

25610 

25611 

25612 

25613 

25614 

25615 

25616 

25617 

25618 

25619 

25620 

25621 

25622 

25623 

25624 

25625 

25626 

25627 

25628 

25629 

25630 

25631 

25632 

25633 

25634 

25635 

25636 

25637 

25638 

25639 

25640 

25641 

25642 

25643 

25644 

25645 

25646 

25647 

25648 

25649 

25650 

25651 

25652 

25653 

25654 

25655 

25656 

25657 

25658 


r = EINVAL; 

} 

next_new_superdirp = advance(new_superdirp, dot2); 

put_inode(new_superdirp); 
if (next_new_superdirp = new_superdirp) 

break; /* vuelta a dir raíz del sist */ 

new_superdirp = next_new_superdirp; 
if (new_superdirp = NIL_INÓDE) { 

/* Falta entrada".suponer lo peor. */ 
r = EINVAL; 

} 

} 

put_inode(new_superdirp); 

} 


/* Nombre viejo o nuevo no debe ser. ni ..*/ 
if (strcmp(old_name, ",")=0 11 strcmp(old_name, ". ,")=0 11 

strcmp(new_name, ",")=011 strcmp(new_name, ",.")=0) r = EINVAL; 

/* Ambos dirs padre deben estar en el mismo dispositivo. */ 
if (old_dirp->i_dev != new_dirp->i_dev) r = EXDEV; 

/* Dirs padre deben ser escribibles, buscables y en un disp escribible. */ 
if ((rl = forbidden(old_dirp, W_BIT 1 X_BIT» != OK 11 

(rl = forbidden(new_dirp, W_BIT IX_BIT» 1 = OK) r = rl; 

/* Algunas pmebas aplican sólo si existe la nva ruta. */ 
if (new_ip = NIL INODE) { 

/* no renombrar arch que tiene un FS montado. */ 
if (old_ip->i_dev != old_dirp->i_dev) r = EXDEV; 
if (odir && (new_dirp->i_nlinks & BYTE) >= LINKMAX && 
!same_pdir && r = OK) r = EMLINK; 

} else { 

if (old_ip = new_ip) r = SAMEj /* viejo=nuevo */ 

/* ¿el arch viejo o nuevo tiene un sistema de archivos montado? */ 
if (old_ip->i_dev != new_ip->i_dev) r = EXDEV; 

ndir = ((new_ip->i_mode & I TYPE) = IDIRECTORY); /* ¿dir? */ 
if (odir = TRUE && ndir = FALSE) r = ENOTDIR; 
if (odir == FALSE && ndir = TRUE) r = EISDIR; 

} 

} 

/* Si un proceso tiene otro directorio raíz que el del sistema, 

* podríamos mover "accidentalmente" su directorio de trabajo 

* a un lugar donde su directorio raíz ya no sea superdirectorio suyo. 

* Esto puede hacer inútil la función chroot. Si se usará chroot 

* a menudo, tal vez debamos tratar de detectarlo aquí. 

*/ 

/* El cambio de nombre quizá funcionará. Ya sólo puede haber 2 problemas: 

* 1. no poder quitar el nuevo archivo (si ya existe) 

* 2. no poder crear la nueva entrada de dir (arch nuevo no existe) 

* [el directorio tiene que crecer en un bloque y no puede 

* porque el disco está totalmente lleno]. 



876 


ArchivQ: src/fs/link.c EL CÓDIGO FUENTE DE MINIX 


25660 

25661 

25662 

25663 

25664 

25665 

25666 

25667 

25668 

25669 

25670 

25671 

25672 

25673 

25674 

25675 

25676 

25677 

25678 

25679 

25680 

25681 

25682 

25683 

25684 

25685 

25686 

25687 

25688 

25689 

25690 

25691 

25692 

25693 

25694 

25695 

25696 

25697 

25698 

25699 

25700 

25701 

25702 

25703 

25704 

25705 

25706 

25707 

25708 

25709 

25710 

25711 

25714 /* 

25715 
25716*= 

25717 

25718 

25719 


if (new_ip != NILINODE) { 

/* Ya hay 1 entrada para ’new'. Tratar de quitarla. */ 

if (odir) 

r = remove_dir(new_dirp, new_ip, new_name); 

else 

r = unlink_file(new_dirp, new_ip, new_name); 

} 

/* Si r es OK, se cambiará el nombre; ahora hay una entrada 
* no utilizada en el nuevo directorio padre. 


if (r = OK) { 

/* Si el nuevo nombre estará en el mismo dir padre que el viejo, 

* primero quitar el viejo a fin de liberar una entrada para el nuevo 

* nombre. Si no, primero tratar de crear la nueva entrada de nombre 

* para asegurar que el cambio de nombre tenga éxito. 

numb = old_ip->i_num; /* núm nodo-i de archivo viejo */ 

if (same_pdir) { 

r = search_dir(old_dirp, old_name, (ino_t *) 0, DELETE); 

/* no debería fallar. */ 

if (r=OK) (void) search_dir(old_dirp, new_name, &numb, ENTER); 

} else { 

r = search_dir(new_dirp, new_name, &numb, ENTER); 
if (r = OK) 

(void) search_dir(old_dirp, old_name, (ino_t *) 0, DELETE); 

} 

} 

/* Si r es OK, ctime y mtime de old_dirp se habrán marcado 
* para actualización en search_dir. 

*/ 

if (r = OK && odir && !same_pdir) { 

/* Actualizar entrada., en directorio (aún apunta a old_dirp). */ 
numb = new_dirp->i_num; 

(void) unlink_file(old_ip, NIL_INODE, dot2); 
if (search_dir(old_ip, dot2, &numb, ENTER) = OK) { 

/* Nuevo vínculo creado. */ 
new_dirp->i_nlinks++; 
new_dirp->i_dirt = DIRTY; 

} 

} 

/* Liberar los nodos-i. */ 
put_inode(old_dirp); 
put_inode(old_ip); 
put_inode(new_dirp); 
put_inode(new_ip); 
retum(r = SAME ? OK : r); 

} 


trúncate 


PUBLIC void truncate(rip) 
register struct inode *rip; 

{ 




/* apuntador a nodo-i por truncar */ 
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25720 /* Quitar todas las zonas del nodo-i 'rip' y marcarlo sucio. */ 

25721 

25722 register block_t b; 

25723 zone_t z, zone_size, zl ; 

25724 off_~ position; 

25725 int i, scale, file_type, waspipe, single, nr_indirects; 

25726 st ruct buf *,bp; 

25727 dev_t dev; 

25728 

25729 filejype = rip->i_mode & I_TYPE; /* Ver si arch es especial */ 

25730 if (file_type = I CHAR SPECIAL 11 file_type == I BLOCK SPECIAL) retum; 

25731 dev = rip->i_dev; /* disp en que reside nodo-i */ 

25732 scale = rip->i_sp->s_log_zone_size; 

25733 zone_size = (zone_t) BLOCK SIZE « scale; 

25734 nr_indirects = rip->i_nindirs; 

25735 

25736 /* Conductos pueden encogerse; ajustar tamaño p/quitar todas zonas. */ 

25737 waspipe = rip->i_pipe == I_PIPE; /* TRUE si era un conducto */ 

25738 if (waspipe) rip->i_size = PIPE SIZE; 

25739 

25740 /* Recorrer archivo zona x zona, hallando y liberando las zonas. */ 

25741 for (position = 0; position < rip->i_sizej position += zone_size) { 

25742 if ( (b = read_map(rip, position)) != NO_BLOCK) { 

25743 z = (zone_t) b» scale; 

25744 ffee_zone(dev, z); 

25745 } 

25746 } 

25747 

25748 /* Todas las zonas de datos liberadas. Liberar zonas de indirección. */ 

25749 rip->i_dirt = DIRTY; 

25750 if (waspipe) { 

25751 wipe_inode(rip); /* despejar nodo-i p/conductos */ 

25752 retum; /* ranuras indirec contienen pos archivos */ 

25753 } 

25754 single = rip->i_ndzones; 

25755 free_zone(dev, rip->i_zone[single]); /* zona indirec sencilla */ 

25756 if ( (z = rip->i_zone[single+l ]) != NO_ZONE) { 

25757 /* Liberar todas las zonas de indirec sene a que apunta la doble. */ 

25758 b = (block_t) z« scale; 

25759 bp = get_block(dev, b, NORMAL); /* obt zona doble indirec */ 

25760 for (i = 0; i < nr_indirects; i++) { 

25761 zl =rd_indir(bp,i); 

25762 free_zone(dev, zl); 

25763 } 

25764 

25765 /* Ahora liberar la zona de doble indirección misma. */ 

25766 put_block(bp, INDIRECT BLOCK); 

25767 free_zone(dev, z)j 

25768 } 

25769 

25770 /* Dejar núms de zona pique de(l) recupere archivo después de unlink(2). 

25771 } 

25774/*=== = = = ==== = = = = = = == = = = ==== = = = == = = = = = = = = = == == = = = = == = 

25775 * remove_dir 

25776 *== == ==== ==■ ■-= == === = ===== = ====== === 

25777 PRIVATE int remove_dir(rldirp, rip, dir_name) 

25778 strnct inode *rldirp; /* directorio padre */ 

25779 strnct inode *rip;/* directorio por eliminar */ 
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25780 char dir_name[NAME_MAX]; /* nombre dir por eliminar */ 

25781 { 

25782 /* Debe eliminarse un arch de directorio. Deben cumplirse 5 condiciones: 

25783 * -El archivo debe ser un directorio 

25784 * -El directorio debe estar vacío (excepto por. y ..) 

25785 * El componente final de la ruta no debe ser. ni.. 

25786 * -El dir no debe ser raíz de un sistema de archivos montado 

25787 * -El dir no debe ser directorio raíz/de trabajo de nadie 

25788 */ 

25789 

25790 int r; 

25791 register struct fproc *rfp; 

25792 

25793 /* search_dir verifica que rip también es un directorio. */ 

25794 if ((r = search_dir(rip, (ino_t *) 0, IS_EMPTY)) != OK) retum r; 

25795 

25796 if (strcmp(dir_name, ".") = 011 strcmp(dir_name, ". .") = 0)retum(EINVAL); 

25797 if (rip->i_num = ROOTINODE) return(EBUSY); /* impos elim ’roof */ 

25798 

25799 for (rfp = &fproc[INIT_PROC_NR + 11; rfp < &fproc[NR_PROCSl; rfp++) 

25800 if (rfp->fp_workdir = rip II rfp->fp_rootdir = rip) retum(EBUSY); 

25801 /* imposible eliminar el dir de trabajo de alguien */ 

25802 

25803 /* Tratar de desvincular archivo; falla si padre es modo 0 etc. */ 

25804 if ((r = unlink_file(rldirp, rip, dir_name)) 1= OK) retum r; 

25805 

25806 /* Desvincular, y ..del dir. El superusuario puede vincular y desvincular 

25807 * cualquier dir, así que no suponer demasiado acerca de ellos. 

25808 */ 

25809 (void) unlink_file(rip, NILINODE, dotl); 

25810 (void) unlink_file(rip, NIL INODE, dot2); 

25811 retum(OK); 

25812 } 

25815/*==========================================================* 

25816 * unlink_file * 

25817 * =—-= = = ===== == ============== == ============ == =*/ 

25818 PRIVATE int unlink_file(dirp, rip, file_name) 

25819 struct inode *dirp; /* dir padre del archivo */ 

25820 struct inode *rip; /* nodo-i del arch, puede ser NIL INODE. */ 

25821 char file_name[NAME_MAXl; /* nombre archivo por eliminar */ 

25822 { 

25823 /* Desvinc. 'file_name'; rip debe ser nodo-i de ’file_name' o NIL_INODE. */ 

25824 

25825 ino_t numb; /* número de nodo-i */ 

25826 int r; 

25827 

25828 /* Si rip no es NIL_INODE, se usa p/acceso más rápido al nodo-i. */ 

25829 if (rip = NIL INODE) { 

25830 /* Buscar archivo en dir y tratar de obtener su nodo-i. */ 

25831 err_code = search_dir(dirp, file_name, &numb, LOOK_UP); 

25832 if (err_code = OK) rip = get_inode(dirp->i_dev, (int) numb); 

25833 if (err code 1= OK II rip = NIL INODE) retum(err code); 

25834 } else { 

25835 dup_inode(rip); /* se devolverá nodo-i con put_inode * 

25836 } 

25837 

25838 r = search_dir(dirp, file_name, (ino_t *) 0, DELETE); 

25839 
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25840 if(r = OK){ 

25841 rip->i_nlinks—; /* entrada eliminada de dir padre */ 

25842 rip->i_update 1= CTIME; 

25843 rip->i_dirt = OIRTY; 

25844 } 

25845 

25846 put_inode(rip); 

25847 retum(r); 

25848 } 


src/fs/stadir.c 

25900 

/* Este archivo contiene el c< 

ádigo para ejecutar cuatro llamadas 


25901 

* al sistema relacionadas coi 

n la situación y los directorios. 


25902 

* 



25903 

* Los puntos de entrada a es 

te archivo son 


25904 

* do chdir: ejecuta la llai 

mada al sistema CHOIR 


25905 

* do chroot: ejecuta la 11 

amada al sistema CHROOT 


25906 

* do stat: ejecuta la llamada al sistema STAT 


25907 

* do fstat: ejecuta la lian 

rada al sistema FSTAT 


25908 

*/ 



25909 




25910 

#include "fs.h" 



25911 

#include <sys/stat.h> 



25912 

#include "file.h" 



25913 

#include "fproc.h" 



25914 

#include "inode.h" 



25915 

#include "param.h" 



25916 




25917 

FORWARO PROTOTYPE( i 

nt change, (struct inode **iip, char *i 

tiame_ptr, int len)); 

25918 

FORWARO PROTOTYPE( i 

nt stat inode, (struct inode *rip, struc 

:t filp *fil_ptr, 

25919 


char *user addr) 

); 

25920 




25922 

25923 * 

* 

do_chdir 

-*, 


25924 PUBLIC int do_chdir() 

25925 { 

25926 /* Cambiar directorio. MM llama también esta función para simular un chdir 

25927 * al ejecutar EXEC, etc. También cambia el directorio raíz, los uids y gids, 

25928 * Y la máscara. 

25929 */ 

25930 

25931 int r; 

25932 register struct fproc *rfp; 

25933 

25934 if (who = MMPROCJSÍR) { 

25935 rfp = &fproc[slotl]; 

25936 put_inode(fp->íp_rootdir); 

25937 dup_inode(fp->fp_rootdir = rfp->fp_rootdir); 

25938 put_inode(fp->íp_workdir); 

25939 dup_inode(fp->fp_workdir = rfp->fp_workdir); 

25940 

25941 /* MM usa access() para verificar permisos. Para que funcione, suponer 

25942 * que los id reales del usuario son iguales a los efectivos. Las llamadas 

25943 * del FS aparte de access() no usan los id reales, así que no resultan 

25944 * afectadas. 
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25945 

25946 

25947 

25948 

25949 

25950 

25951 

25952 

25953 

25954 

25955 

25956 

25957 

25960 /*= 

25961 

25962 *= 

25963 

25964 

25965 

25966 

25967 

25968 

25969 

25970 

25971 

25972 

25975 /*= 

25976 

25977 *= 

25978 

25979 

25980 

25981 

25982 

25983 

25984 

25985 

25986 

25987 

25988 

25989 

25990 

25991 

25992 

25993 

25994 

25995 

25996 

25997 

25998 

25999 

26000 
26001 
26002 

26003 

26004 


fp->fp_realuid = 
fp->fp_effuid = rfp->fp_effiiid; 
fp->fp_realgid = 
fp->fp_effgid = rfp->fp_effgidj 
fp->fp_umask = rfp->fp_umask; 
retum(OK); 


/* Ejecutar la llamada al sistema chdir(name). */ 
r = change(&fp->fp_workdir, ñame, name_length)j 
retum(r); 


do_chroot 


PUBLIC int do_chroot() 

{ 

/* Ejecutar la llamada al sistema chroot(name). */ 
register int r; 

if (! super_user) retum(EPERM); /* sólo su puede chroot() */ 

r = change(&fp->íp_rootdir, ñame, name_length); 

retum(r); 

} 


change 


PRIVATE int change(iip, name_ptr, len) 

struct inode **iip; /* apunt a apunt nodo-i piel dir */ 

char *name_ptr; /* apunt al nombre dir a cambiar */ 

int lenj /* long cadena de nombre del dir */ 

{ 

/* Realizar el trabajo real de chdir() y chroot(). */ 

struct inode *rip; 
register int r; 

/* Tratar de abrir el nuevo directorio. */ 

if (fetch_name(name_ptr, len, M3) != OK) retum(err_code); 

if ( (rip = eat_path(uSer_path)) == NIL_INODE) retum(err_code); 

/* Debe ser un directorio y también buscable. */ 
if ( (rip->i_mode & I TYPE) != I DIRECTORY) 
r = ENOTDIR; 
else 

r = forbidden(rip, X_BIT); /* ver si dir es buscable */ 

/* Si hay error, devolver nodo-i. */ 
if (r != OK) { 
put_inode(rip); 
retum(r); 

} 

/* Todo bien. Hacer el cambio. */ 


=*/ 


=*/ 
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26005 put_inode(*iip) 

26006 *iip = rip; 

26007 retum(OK); 

26008 } 

26011 /*====. === ====== 

26012 * 

26013 *== = = = ======== 

26014 PUBLIC int do_stat() 

26015 { 

26016 /* ejecutar la llamada al sistema stat(name, buf). */ 

26017 

26018 register struct inode *rip; 

26019 register int r; 

26020 

26021 /* Stat() y fstat() usan la misma rutina para efectuar el trabajo real. Esa rutina 

26022 * espera un nodo-i, así que lo adquirimos temporalmente. 

26023 */ 

26024 if (fetch_name(name 1, ñame l_length, MI) 1= OK) retum(err_code); 

26025 if ( (rip = eat_path(user_path)) = NIL_INODE) retum(err_code); 

26026 r = stat_inode(rip, NIL_FILP, name2); /* Hacer realmente el trabajo.*/ 

26027 put_inOde(rip); /* liberar nodo-i */ 

26028 retum(r); 

26029 } 

26032 /*====== = ======================= ==== ============== 

26033 * do_fstat 

26034 *====================== = ============== == ========= 

26035 PUBLIC int do_fstat() 

26036 { 

26037 /* Ejecutar la llamada al sistema fstat(fd, buf). */ 

26038 

26039 register struct filp *rfílp; 

26040 

26041 /* ¿Es válido el descriptor de archivo? */ 

26042 if ( (rfilp = get_filp(fd)) = NIL_FILP) retum(err_code); 

26043 

26044 retum(stat_inOde(rfüp->filp_ino, rfilp, buffer)); 

26045 } 

26048 /*= = = = = == === = ==== = === = == == = = = = = == = = = = ==- == == 

26049 * stat_inode 

26050 *====================== = === -■ - ■-= ======= == ========= 

26051 PRIVATE int stat_inode(rip, fil_ptr, user_addr) 

26052 register struct inode *rip; /* apunt a nodo-i p/stat */ 

26053 struct filp *fil_ptr; /* apunt filp, proporc por ’fstat' */ 

26054 char *user_addr; /* dir espacio usuario p/buf stat */ 

26055 { 

26056 /* Código común para las llamadas al sistema stat y fstat. */ 

26057 

26058 struct stat statbuf; 

26059 modet mo; 

26060 int r, s; 

26061 

26062 /* Actualizar campos atime, ctime y mtime del nodo-i, si necesario. */ 

26063 if (rip->i_update) update_times(rip); 

26064 


/* liberar directorio viejo */ 
/* adquirir el nuevo */ 


do_stat 
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26065 /* Llenar la estructura statbuf. */ 

26066 mo = rip->i_mode & ITYPE; 

26067 s = (mo = I CHAR SPECIAL 11 mo = IBLOCKSPECIAL); /* TRUE si especial */ 

26068 statbuf. st_dev = rip->i_dev; 

26069 statbuf.st_ino = rip->i_num; 

26070 statbuf. stmode = rip->i_mode; 

26071 statbuf. s.t_nlink = rip ->i_nlinks & BYTE; 

26072 statbuf.st_uid = rip->i_uid; 

26073 statbuf. st_gid = rip->i_gid & BYTE; 

26074 statbuf.st_rdev = (dev_t) (s ? rip->i_zone[0] : NO_DEV); 

26075 statbuf. st_size = rip->i_size; 

26076 

26077 if (rip->i_pipe = I_PIPE) { 

26078 statbuf.st mode &= -I REGULARj /* borrar bit I REGULAR p/conductos */ 

26079 if (fil_ptr != NIL FILP && fil_ptr->filp_mode & R BIT) 

26080 statbuf. st_size -= fil_ptr->filp_pos; 

26081 } 

26082 

26083 statbuf. st_atime = rip->i_atime; 

26084 statbuf. st_mtime = rip->i_mtime; 

26085 statbuf. st_ctime = rip->i_ctime; 

26086 

26087 /* Copiar la estructura en el espacio de usuario. */ 

26088 r = sys copy (FS PROC NR , D, (phys bytes) &statbuf, 

26089 who, D, (phys_bytes) user_addr, (phys_b)4es) sizeof(statbuf)); 

26090 retum(r); 

26091 } 


src/fs/protect.c 


26100 /* Este archivo maneja la protección en el sistema de archivos; contiene 

26101 * el código de 4 llamadas al sistema relacionadas con protección. 

26102 * 

26103 * Los puntos de entrada a este archivo son 

26104 * do chmod: ejecutar la llamada al sistema CHMOD 

26105 * do_chown: ejecutar la llamada al sistema CHOWN 

26106 * do_umask: ejecutar la llamada al sistema UMASK 

26107 * do_access: ejecutar la llamada al sistema ACCESS 

26108 * forbidden: ver si acceso dado permitido a un nodo-i dado 

26109 */ 

26110 

26111 #include "fs.h" 

26112 #include <unistd.h> 

26113 #include <minix/callnr.h> 

26114 #include "buf. h" 

26115 #include "file.h" 

26116 #include "fproc.h" 

26117 #include "inode.h" 

26118 #include "param.h" 

26119 #include "super.h" 

26120 

26121 /* = === = ====================== = = ==== ============ 

26122 * do_chmod 

26123 *== === = === == ===== = ===== = ===== == 

26124 PUBLIC int do_chmod() 
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26125 { 

26126 /* Ejecutar la llamada al sistema ChmOd(name, mode). */ 

26127 

26128 register struct mode *rip; 

26129 register int r; 

26130 

26131 /* Abrir 'temporalmente el archivo. */ 

26132 if (fetch_name(name, name_length, M3) != OK) return(err_code); 

26133 if ( (rip = eat_path(user_path» == NIL_INODE) retum(err_cOde); 

26134 

26135 /* Sólo el dueño o el su puede cambiar el modo de un archivo. Nadie puede cambiar 

26136 * el modo de un arch en un sistema de archivos sólo de lectura. 

26137 */ 

26138 if (rip->i_uid 1 = fP->fp_effuid && ! super_user) 

26139 r = EPERM; 

26140 else 

26141 r = read_only(rip); 

26142 

26143 /* Si hay error, devolver nodo-i. */ 

26144 if (r != OK) { 

26145 put_inOde(rip); 

26146 retum(r); 

26147 } 

26148 

26149 /* Hacer cambio. Apagar bit setgid si arch no en grupo del invocador */ 

26150 rip->i_mode = (rip->i_mode & -ALLMODES) I (mode & ALLMODES); 

26151 if (!super_user && rip->i_gid != fp->fp_effgid)rip->i_mode &= -I_SET_GID_BIT; 

26152 rip->i_update 1= CTIME; 

26153 rip->i_dirt = DIRTY; 

26154 

26155 put_inOde(rip); 

26156 return(OK); 

26157 } 

26160 /*===================================================== == == = 

26161 * do chown * 

26162 *========================-= = ========= = ====== === ===== = = 

26163 PUBLIC int do_Chown() 

26164 { 

26165 /* Ejecutar la llamada al sistema chown(name, owner, group). */ 

26166 

26167 register struct inode *rip; 

26168 register int r; 

26169 

26170 /* Abrir temporalmente el archivo. */ 

26171 if (fetch_name(name 1, ñame l_length, M1) != OK) retum(err_code); 

26172 if ( (rip = eat_path(user_path» = NIL_INODE) retum(err_code); 

26173 

26174 /* No se permite cambiar dueño de un arch en un sist arch sólo de lectura. */ 

26175 r = read_only(rip); 

26176 if (r = OK) { 

26177 /* FS es R/W. Que se permita llamada o no depende de dueño, etc. */ 

26178 if (super_user) { 

26179 /* El superusuario puede hacer todo. */ 

26180 rip->i_uid = owner; /* otros después */ 

26181 } else { 

26182 /* Usuarios normales sólo pueden cambiar grupos de arch propios. */ 

26183 if (rip->i_Uid != fp->fp_effuid) r = EPERM; 

26184 if (rip->i_uid != owner) r = EPERM; /* no regalar */ 
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26185 if (fP->fp_effgid 1= groUp) r = EPERM; 

26186 } 

26187 } 

26188 if (r — OK) { 

26189 rip->i_gid = group; 

26190 rip->i~mode &= -(I SET UID BIT II SET GID BIT); 

26191 rip->i_uPdate 1= CTIME; 

26192 rip->i_dirt = DIRTY; 

26193 } 

26194 

26195 put_inOde(rip); 

26196 return(r); 

26197 } 

26200 /*============= = ================ = ====== == =============== 

26201 * do_umask 

26202 ♦= = ==== = == = ==================== = ===================== == 

26203 PUB1IC int do_umaSk() 

26204 { 

26205 /* Ejecutar la llamada al sistema Umask(co_mOde) o */ 

26206 register mode_t r; 

26207 

26208 r = -fp->fp_umask; /* hacer Y = complemento másco Vieja */ 

26209 fp->fP_umask = -(Co mode & RWX MODES); 

26210 retum(r); /* devolver complemento máscara vieja */ 

26211 } 

26214 /*= = = == = == = = = == = == == = = ===== = = = = = == = = = = = == === == : 

26215 * do_access 

26216 * ======================================== 

56217 PUB1IC int do_access() 

26218 { 

26219 /* Ejecutar la llamada al Sistema access(name, mode). */ 

26220 

26221 struct inOde *rip; 

26222 register int r; 

26223 

26224 /* Primero ver si el modo es el Correcto. */ 

26225 if ( (mode & -(R_OK I W_OK I X_OK» 1= 0 && mode != F_OK) 

26226 retum(EINVAl); 

26227 

26228 /* Abrir temporalmente el archivo cuyO acceso se verificará. */ 

26229 if (fetch_name(name, name_length, M3) 1= OK) retum(err_COde); 

26230 if ( (rip = eat_path(user_path» = NIl_INODE) retum(err_COde); 

26231 

26232 /* Ahora verificar los permisos. */ 

26233 r = forbidden(rip, (mode_t) mOde); 

26234 put_inOde(rip); 

26235 retum(r); 

26236 } 

26239 1* ====================== 

26240 * forbidden 

26241 *== = = = === = =========== = === = ==== = = = == = == = ===== ==== = 

26242 PUB1IC int forbidden(rip, access_desired) 

26243 register struct inOde *rip; /* apunt a nodo-i por verificar */ 

26244 mode_t access_desired; l*bitsRWX */ 
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26245 { 

26246 

26247 

26248 

26249 

26250 

26251 

26252 

26253 

26254 

26255 

26256 

26257 

26258 

26259 

26260 
26261 
26262 

26263 

26264 

26265 

26266 

26267 

26268 

26269 

26270 

26271 

26272 

26273 

26274 

26275 

26276 

26277 

26278 

26279 

26280 
26281 
26282 

26283 

26284 

26285 

26286 

26287 

26288 

26289 

26290 

26291 

26292 

26293 

26294 

26295 

26296 

26297 

26298 } 

26301 /*== 

26302 
26303*=== 
26304 


/* Dado un apuntador a un nodo-i, 'rip' y el acceso deseado, determinar 

* si éste se permite, y si no, por qué. La rutina busca el uid del invocador 

* en la tabla ’fproc'. Si se permite el acceso, se devuelve OK. Si no, 

* se devuelve EACCES. 


register struct inode *old_rip = rip; 
register struct super_block *sp; 
register mode_t bits, perm_bits; 
int r, shift, test_uid, test_gid; 

if (rip->i_mount = I_MOUNT) /* Sist montado en nodo-i. */ 

for (sp = &super_block[l]; sp < &super_block[NA_SUPEAS] j sp++) 
if (sp->s_imount = rip) { 

rip = get_inode(sp->s_dev, AOOTINODE); 

} /* if */ 

/* Aislar los bits rwx pertinentes del modo. */ 
bits = rip->i_mode; 

test_uid = (fs_call = ACCESS ? fp->fp_realuid : fp->fp_effuid); 
test_gid = (fs_call = ACCESS ? fp->fp_realgid : fp->fp_effgid)j; 
if (test uid = SU UID) { 

/* Conceder permiso de leer y escribir. Conceder permiso de búsqueda 

* directorios. Conceder permiso ejecución (pino directorios) si 

* Y sólo si uno de los bit s 'X' está encendido. 

*/ 

if ( (bits & I TYPE) = I DIAECTOAY 11 

bits & ((XBIT « 6) I (XBIT « 3) IXBIT)) 
perm bits = A BIT I W_BIT IX BIT; 

permbits = ABIT 1 W_BIT; 

} else { 

if (test_uid = rip->i_uid) shift = 6; /* dueño */ 

else if (test_gid = rip->i_gid ) shift = 3; /* grupo */ 

else shift = 0; /* otro */ 

perm bits = (bits » shift) & (A BIT 1 W_BIT I X_BIT)j 

} 


/* Si el acceso deseado no es subconjunto de lo permitido, se niega. */ 
r = OK; 

if ((perm_bits 1 access_desired) != perm_bits) r = EACCES; 

/* Ver si alguien está tratando de escribir en un sistema de archivos que está 
* montado sólo para lectura. 

*/ 

if (r = OK) 

if (access_desired & W_BIT) r = read_only(rip); 
if (rip != old_rip) put_inode(rip); 
retum(r); 


read_only 


PUBLIC int read_only(ip) 


*/ 
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26305 struct inode *ip; /* apunt a nodo cuyo FS debe verif */ 

26306 { 

26307 /* Ver si el sistema de archivos en el que el nodo-i ’ip' reside está montado 

26308 * sólo p/lectura. Si sí, devolver EROFS; si no, devolver OK. 

26309 */ 

26310 

26311 register struct 'super_block *sp; 

26312 

26313 sp = ip->i_sp; 

26314 retum(sp->s_rd_only? EROFS : OK); 

26315 } 
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26400 

26401 

26402 

26403 

26404 

26405 

26406 

26407 

26408 

26409 

26410 

26411 

26412 

26413 

26414 

26415 

26416 

26417 

26418 
26419/* 

26420 

26421 *= 

26422 

26423 

26424 

26425 

26426 

26427 

26428 

26429 

26430 

26431 

26432 

26433 

26434 

26435 

26436 

26437 

26438 

26439 


/* Este archivo se ocupa de las llamadas relacionadas con el tiempo. 

* Los puntos de entrada a este archivo son: 

* do_utime: ejecutar la llamada al sistema UTIME 

* do_time: ejecutar la llamada al sistema TIME 

* do_stime: ejecutar la llamada al sistema STIME 

* do_tims: ejecutar la llamada al sistema TIMES 


#include "fs.h" 

#include <minix/callnr.h> 
#include <minix/com.h> 
#include "file.h" 

#include "íproc.h" 

#include "inode.h" 

#include "param.h" 

PRIVATE message clock mess; 


do_utime 


PUBLIC int do_utime() 

{ 

/* Ejecutar la llamada al sistema utime(name, timep). */ 

register struct inode *rip; 
register int len, r; 

/* Ajustar para el caso de NULL 'timep'. */ 
len = utime_length; 
if (len = 0) len = m.m2_i2; 

/* Abrir temporalmente el archivo. */ 
if (fetch_name(utime_file, len, MI) 1= OK) retum(err_code); 
if ( (rip = eat_path(user_path)) — NIL_INODE) retum(err_code); 

/* Sólo dueño del archivo o superusuario pueden cambiar su tiempo. */ 
r = OK; 

if (rip->i_uid 1= fp->fp_effuid && !super_user) r = EPERM; 
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26500 reply_t2 = t[l] 

26501 reply_t3=t[2] 

26502 reply_t4 = t[3] 

26503 reply_t5 = t[4] 

26504 return(OK); 

26505 } 
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26600 

26601 

26602 

26603 

26604 

26605 

26606 

26607 

26608 

26609 

26610 
26611 
26612 

26613 

26614 

26615 

26616 

26617 

26618 

26619 

26620 
26621 
26622 

26623 

26624 

26625 

26626 

26627 

26628 
26629/* 
26630 
26631* 

26632 

26633 

26634 

26635 

26636 

26637 

26638 

26639 

26640 

26641 

26642 

26643 

26644 


/* Este archivo contiene procedimientos diversos. Algunos de ellos ejecutan 

* llamadas sencillas al sistema. Otros hacen una parte de algunas llamadas 

* que el administrador de memoria ejecuta casi en su totalidad. 


* Los puntos de entrada a este archivo son 

* do_dup: ejecutar la llamada al sistema DUP 

* do_fcntl: ejecutar la llamada al sistema FCNTL 

* do_sync: ejecutar la llamada al sistema SYNC 

* do_fork: ajustar tablas después de que MM ejecutó FORK 

manejar archs con FD CLOEXEC encendido después de EXEC por MM 
un proceso salió; anotarlo en las tablas 
establecer uid o gid para algún proceso 

do_revive: revivir proceso que esperaba algo (p.ej. TTY) 


#include "fs.h" 

#include <fcntl.h> 

#include <unistd.h> /* cc se queda sin memoria con unistd.h : -( */ 

#include <minix/callnr.h> 

#include <minix/com.h> 

#include <minix/boot.h> 

#include "buf.h" 

#include "file.h" 

#include "fproc.h" 

#include "inode.h" 

#include "dev.h" 

#include "param.h" 


do_dup 


PUBLIC int do_dup() 

{ 

/* Ejecutar la llamada al sistema dup(fd) o dup2(fd,fd2). Estas son obsoletas. 

* De hecho, ni siquiera podemos invocarlas con la biblioteca actual 

* porque las rutinas de biblioteca invocan fcntl(). Se incluyen para que 

* programas binarios viejos puedan seguir ejecutándose. 

*/ 


register int rfd; 
register struct filp *f; 
struct filp *dummy; 
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26645 /* ¿Es válido el descriptor de archivo? */ 

26646 rfd = fd & -DUP_MASK; /* apagar bit dup2 si encendido */ 

26647 if ((f = get_filp(rfd)) = NILFILP) retum(err code); 

26648 

26649 /* Distinguir entre dup y dup2. */ 

26650 if (fd = rfd) { /* bit apagado */ 

26651 /* dup(fd) */ 

26652 if ( (r = get_fd(0, 0, &fd2, &dummy)) != OK) retum(r); 

26653 } else { 

26654 /* dup2(fd, fd2) */ 

2665 5 if (fd2 < 0 11 fd2 >= OPEN_MAX) retum(EBADF); 

26656 if (rfd = fd2) retum(fd2); /* ignorar llamada: dup2(x, x) */ 

26657 fd = fd2; /* preparar p/cerrar fd2 */ 

26658 (void) do_close(); /* no puede fallar */ 

26659 } 

26660 

26661 /* Éxito. Establecer nuevos descriptores de archivo. */ 

26662 f->filp_count++; 

26663 fp->fp_filp[fd2] = f; 

26664 retum(fd2); 

26665 } 

26667 /* ===== = = = = == === = = == ========= = = = === = == == 

26668 * do_fcntl 

26669 *= = = = = = == = ==== = ============= = == = = = = = ======== == = = = = == = = == = = = = = 

26670 PUBLIC int do_fcntl() 

26671 { 

26672 /* Ejecutar la llamada al sistema fcntl(fd, request, " .). */ 

26673 

26674 register struct filp *f; 

26675 int new_fd, r, fl; 

26676 long cloexecmask; /* mapa bits p/bandera FDCLOEXEC */ 

26677 long clo_value; /* FD_CLOEXEC en posición correcta */ 

26678 struct filp *dummy; 

26679 

26680 /* ¿Es válido el descriptor de archivo? */ 

26681 if ((f = get_filp(fd)) = NIL_FILP) retum(err_code); 

26682 

26683 switch (request) { 

26684 case F DUPFD: 

26685 /* Sustituye a la vieja llamada al sistema dup(). */ 

26686 if (addr <011 addr >= OPEN_MAX) retum(EINVAL); 

26687 if ((r = get_fd(addr, 0, &new_fd, &dummy)) 1= OK) retum(r); 

26688 f->filp_count++; 

26689 fp->fp_filp[new_fd] = f; 

26690 retum(new_fd); 

26691 

26692 case F GETFD: 

26693 /* Obt bandera cerrar-al-ejec (FD CLOEXEC en tabla 6-2 POSIX). */ 

26694 retum( l(fp->fp_cloexec » fd) & 01) ? FD_CLOEXEC : 0); 

26695 

26696 case F SETFD: 

26697 /* Fijar bandera cerrar-al-ejec (FD CLOEXEC en tabla 6-2 POSIX). */ 

26698 cloexec_mask = 1L « fd; /* posic conjunto solo ok */ 

26699 clo value = (addr & FD CLOEXEC ? cloexec mask : 0L); 

26700 fp->fp_cloexec = (fp->fp_cloexec & -cloexec mask) 1 clo value; 

26701 retum(OK); 

26702 

26703 case FGETFL: 

26704 /* Obtener banderas de situación archivo (O NONBLOCK y O APPEND). */ 
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26705 fl = f->filp_flags & (0_N0NBL0CK I 0_APPEND I 0_ACCM0DE); 

26706 retum(fl); 

26707 

26708 case FSETFL: 

26709 /* Fijar banderas de situación archivo (ONONBLOCK y O APPEND). */ 

26710 fl =’0_NONBLOCK I 0_APPEND; 

26711 f->filp_flags = (f->filp_flags & -fl) I (addr & fl); 

26712 retum(OK); 

26713 

26714 case F GETLK: 

26715 case F SETLK: 

26716 case F SETLKW: 

26717 /* Poner o quitar un candado de archivo. */ 

26718 r = lock_op(f, request); 

26719 retum(r); 

26720 

26721 default: 

26722 retum(EINVAL); 

26723 } 

26724 } 

26727 /*==================================================== == == == * 

26728 * do_sync * 

26729 *========================= — ======= === ============= == =*/ 

26730 PUBLIC int do_sync() 

26731 { 

26732 /* Ejecutar llamada al sistema sync(). Vaciar todas las tablas. */ 

26733 

26734 register struct inode *rip; 

26735 register struct buf *bp; 

26736 

26737 /* El orden en que se vacían las tablas es crítico. Los bloques deben 

26738 * vaciarse al final, ya que rw_inode() deja sus resultados en el caché 

26739 * de bloques. 

26740 */ 

26741 

26742 /* Escribir todos los nodos-i sucios en disco. */ 

26743 for (rip = &inode[0]; rip < &inode[NR_INODES]; rip++) 

26744 if (rip->i_count > 0 && rip->i_dirt = DIRTY) rw_inode(rip, WRITING); 

26745 

26746 /* Escribir todos los bloques sucios en disco, una unidad a la vez. */ 

26747 for (bp = &buf[0]; bp < &buf[NR_BUFS]; bp++) 

26748 if (bp->b_dev 1= NO_DEV && bp->b_dirt = DIRTY) flushall(bp->b_dev); 

26749 

26750 retum(OK); /* sync() no puede fallar */ 

26751 } 

26754 /*===================================================== == == == * 

26755 * dofork * 

26756 *===================================== === ============= == =*/ 

26757 PUBLIC int do_fork() 

26758 { 

26759 /* Realizar los aspectos de la llamada fork() relacionados con archivos. En 

26760 * particular, que el hijo herede los descriptores de archivo de su padre. Los 

26761 * parámetros de padre e hijo dicen quién bifurcó a quién. El sistema de archivos 

26762 * usa los mismos números de ranura que el kemel. Sólo MM efectúa esta llamada. 

26763 */ 

26764 
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26765 register struct fproc *cp; 

26766 int i; 

26767 

26768 /* Sólo MM puede hacer esta llamada directamente. */ 

26769 if (who != MM_PROC_NR) retum(EGENERIC); 

26770 

26771 /* Copiar estructura fproc del padre al hijo. */ 

26772 fproc [child] = fproc [parent]; 

26773 

26774 /* Aumentar contadores en la tabla 'filp'. */ 

26775 cp = &fproc[child]; 

26776 for (i = 0; i < OPEN MAX; i++) 

26777 if (Cp->fp_filp[i] != NILFILP) cp->fp_fllp[i] ->filp_count++; 

26778 

26779 /* Llenar nuevo id de proceso. */ 

26780 cp->fp_pid = pid; 

26781 

26782 /* Un hijo no es un jefe de proceso. */ 

26783 cp->fp_sesldr = 0; 

26784 

26785 /* Registrar hecho de que dir raíz y de trabajo tienen otro usuario. */ 

26786 dup_inode(cp->fp_rootdir); 

26787 dup_inode(cp->fp_workdir); 

26788 retum(OK); 

26789 } 

26792 /*= = = = = == = = = = = = === = = = === === = = = = = = = = = == == == = = = ==== = 

26793 * doexec 

26794 *== = ====== = ======= = ==== = === = = = = === === = == == = = === = == == = 

26795 PUBLIC int do_exec() 

26796 { 

26797 /* Podemos marcar archivos con el bit FOCLOEXEC (en fp->fp_cloexec). Cuando MM 

26798 * efectúa un EXEC, llama al FS para que él pueda encontrar estos archivos y los cierre: 

26799 */ 

26800 

26801 register int i; 

26802 long bitmap; 

26803 

26804 /* Sólo MM puede hacer esta llamada directamente. */ 

26805 if (who != MM_PROC_NR) retum(EGENERIC); 

26806 

26807 /* El arreglo de bit s FO_CLOEXEC está en el mapa de bits fd_cloexec. */ 

26808 fp = &fproC[slotl]; /* get_filp() necesita 'fp' */ 

26809 bitmap = fp->fp_cloexec; 

26810 if (bitmap = 0) retum(OK)j /* caso normal, ningún FO CLOEXEC */ 

26811 

26812 /* Revisar descriptores de archivo 1 por 1 p/detectar FO_CLOEXEC. */ 

26813 for (i = 0; i < OPEN_MAX; i++) { 

26814 fd = i; 

26815 if ( (bitmap » i) «fe 01) (void) do_close(); 

26816 } 

26817 

26818 retum(OK); 

26819 } 

26822 /*= === = == ==== === = == = === = === = === = === = 

26823 * do_exit 

26824 *== = ======== = === = == === === == = = === = ===== = == == = 
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26825 PUBLIC int do_exit() 

26826 { 

26827 /* Realizar la porción de la llamada exit(status) que toca al FS. */ 

26828 

26829 register int i, exitee, task; 

26830 register struct fproc *rfp; 

26831 regist,er struct fdp *rfilp; 

26832 register struct inode *rip; 

26833 int majar; 

26834 dev_t dev; 

26835 message devmess; 

26836 

26837 /* Sólo el MM puede efectuar la llamada EXIT directamente. */ 

26838 if (who != MM_PROC_NR) retum(EGENERIC); 

26839 

26840 * No obstante, fingir que la llamada provino del usuario. */ 

26841 fp = &fproc[slotl]; /* get_filp() necesita ’fp' */ 

26842 exitee = slot 1; 

26843 

26844 if (fp->fp_suspended = SUSPENDED) { 

26845 task = -fp->fp_task; 

26846 if (task == XPIPE II task = XPOPEN) susp_count~; 

26847 pro = exitee; 

26848 (void) do_unpause(); 1 * esto siempre tiene éxito p/MM *1 

26849 fp->fp_suspended = NOTSUSPENDED; 

26850 } 

26851 

26852 /* Iterar en descriptores de archivo, cerrando los abiertos. */ 

26853 for (i = 0; i < OPEN_MAX; i++) { 

26854 fd = i; 

26855 (void) do_close(); 

26856 } 

26857 

26858 /* Liberar directorios raíz y de trabajo. */ 

26859 put_inode(fp->fp_rootdir); 

26860 put_inode(fp->fp_workdir); 

26861 fp->fp_rootdir = NILINODE; 

26862 fp->fp_workdir = NILINODE; 

26863 

26864 /* Si existe un jefe de sesión, revocar acceso a su tty controladora 

26865 * desde todos los otros procesos que la usan. 

26866 */ 

26867 if (!íp->íp_sesldr) retum(OK); /* no es jefe de sesión */ 

26868 fp->fp_sesldr = FALSE; 

26869 if (fp->fp_tty = 0) retum(OK); /* no es tty controladora */ 

26870 dev = fp->fp_tty; 

26871 

26872 for (rfp = &fproc[LOWJJSER]; rfp < &fproc[NR_PROCS]; rfp++) { 

26873 if (rfjp->fp_tty = dev) rfp->fp_tty = 0; 

26874 

26875 for (i = 0; i < OPEN_MAX; i++) { 

26876 if ((rfilp = rfp->fp_filp[i]) = NIL_FILP) continué; 

26877 if (rfilp->filp_mode = FILP CLOSED) continué; 

26878 rip = rfilp->filp_ino; 

26879 if ((rip->i_mode & I TYPE) 1= I CHAR SPECIAL) continué; 

26880 if ((dev_t) rip->i_zone[0] 1= dev) continué; 

26881 dev_mess.m_type = DEV_CLOSE; 

26882 dev mess.DEVICE = dev; 

26883 majar = (dev » MAJOR) & BYTE; /* núm disp principal */ 

26884 task = dmapjlllajor] .dmap_task; /* núm tarea dispositivo */ 



EL CÓDIGO FUENTE DE MINIX 


Archivo: src/fs/misc.c 


893 


26885 (*dmap[major] ,dmap_close) (task, &dev_mess)j 

26886 rfilp->filp_mode = FILPCLOSEDj 

26887 } 

26888 } 

26889 retum(OK); 

26890 } 

26893/*=============================================================== 

26894 * do_set * 

26895 *=============================================================*; 


26896 PUBLIC int do_set() 

26897 { 

26898 /* Establecer campo uid_t o gid t. */ 

26899 

26900 register struct fproc *tfp; 

26901 

26902 /* Sólo MM puede hacer esta llamada directamente. */ 

26903 if (who 1= MM_PROC_NR) retum(EGENERIC); 

26904 

26905 tfp = &fproc[slotl]; 

26906 if (fs_call = SETUID) { 

26907 tfp->fp_realuid = (uid_t) real_user_idj 

26908 tfp->fp_effuid = (uid_t) eff_user_idj 

26909 } 

26910 if (fs_call = SETGID) { 

26911 tfp->fp_effgid = (gid_t) eff_grp_idj 

26912 tfjj->í^)_realgid = (gidt) real_grp_idj 

26913 } 

26914 retum(OK); 

26915 } 

269187*==============================================================* 

26919 * do_revive * 

26920*==============================================================*7 

26921 PUBLIC int do_revive() 

26922 { 

26923 /* Una tarea, usualmente TTY, ya obtuvo los caracteres necesarios p/una 

26924 * lectura previa. El proceso no obtuvo respuesta al hacer la llamada, 

26925 * sino que se suspendió. Ahora podemos enviar la respuesta para despertarlo. 

26926 * Hay que tener cuidado, pues el mensaje entrante viene de una tarea 

26927 * (a la que no puede enviarse respuesta), y la respuesta debe ir a un proceso 

26928 * que se bloqueó antes. La respuesta al invocador se inhibe izando 

26929 * la bandera ’dont_reply', y la respuesta al proceso bloqueado se efectúa 

26930 * explícitamente en revive(). 

26931 */ 

26932 

26933 #if IALLOWUSERSEND 

26934 if (who >= LOWJJSER) retum(EPERM)j 

26935 #endif 

26936 

26937 revive (m. REP_PROC_NR , m.REP STATUS); 

2693 8 dont_reply = TRUEj 1 * no responder a tarea TTY *1 

26939 retum(OK); 

26940 } 
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27000 

27001 

27002 

27003 

27004 

27005 

27006 

27007 

27008 

27009 

27010 

27011 

27012 

27013 

27014 

27015 

27016 

27017 

27018 

27019 

27020 

27021 

27022 

27023 

27024 

27025 

27026 

27027 

27028 

27029 

27030 /*= 

27031 

27032 *= 

27033 

27034 

27035 

27036 

27037 

27038 

27039 

27040 

27041 

27042 

27043 

27044 

27045 

27046 

27047 

27048 

27049 

27050 

27051 

27052 

27053 

27054 


/* Si un bloque requerido no está en el caché, debe traerse de disco. Los archivos 
* especiales por caracteres también requieren E/S. Las rutinas para todo esto están aquí. 


* Los puntos de entrada a este archivo son: 

* dev_io: leer o escribir en un disp por bloques o por caracteres 

* dev_opcl: procesam. de abrir y cerrar genérico específico p/disp 

* tty_open: procesamiento de abrir específico p/tty 

* ctty_open: procesam de abrir específico p/tty controladora 

* ctty_close: procesam de cerrar específico p/tty controladora 

* do_setsid: ejecutar llamada al sistema SETSID (lado del FS) 

* do_ioctl: ejecutar llamada al sistema IOCTL 

* call_task: procedim que realmente llama las tareas del kernel 

* call_ctty: procedim que realmente llama tarea para /dev/tty 


#include "fs.h" 

#include <fcntl.h> 
#include <minix/callnr.h> 
#include <minix/com.h> 
#include "dev.h" 

#include "file.h" 

#include "fproc.h" 
#include "inode.h" 
#include "param.h" 


PRIVATE message dev mess; 
PRIVATE majar, minar, task; 


FORWARD _PROTOTYPE( void fmd_dev, (Dev_t dev) 


devio 


PUBLIC int dev_io(op, nonblock, dev, pos, bytes, proc, buff) 

int op; /* DEV READ, DEV WRITE, DEVJOCTL, e 

int nonblock; /* TRUE si op no bloqueadora */ 

dev_t dev; /* núm disp principal-secundario */ 

off_t pos; /* posición de byte */ 

int bytes; /* cuántos bytes por transferir */ 

int proc; /* ¿en esp dir de quién está buff? */ 

char *buff; /* dirección virtual del buffer */ 


/* Leer de o escribir en dispositivo; 'dev' indica cuál. */ 

find_dev(dev); /* cargar variables majar, minar y task */ 

/* Preparar el mensaje que se pasa a la tarea. */ 
devmess.mtype = op; 

dev mess.DEVICE = (dev » MINOR) & BYTE; 
devmess.POSITION = pos; 
devmess.PROCNR = proc; 
devmess.ADDRESS =buff; 
devmess.COUNT = bytes; 

dev_mess.TTY_FLAGS = nonblock; /* arreglo temporal */ 
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27055 /* Invocar la tarea. */ 

27056 (*dmap[major] ,dmap_rw) (task, &dev_mess); 

27057 

27058 /* Tarea acabó. Ver si la llamada acabó. */ 

27059 if (dev_mess.REP_STATUS = SUSPEND) { 

27060 if (op = DEVOPEN) task = XPOPEN; 

27061 suspend(task); /* suspender usuario */ 

27062 } 

27063 

27064 retum(dev_mess.REP_STATUS); 

27065 } 

27068 /*== = = = == = = == == = = = = == == = = = = === = = = = = == = = = = = = = = = === 

27069 * dev_opcl 

27070 ♦==■■■■ -^ == ^:^ ==== = = ===== = = = = ======================= == 

27071 PUBLIC void dev_opcl(task_nr, mess_ptr) 

27072 int task_nr; /* cuál tarea */ 

27073 message *mess_ptr; /* apuntador a mensaje */ 

27074 { 

27075 /* Invocada de struct dmap en table.c al abrir o cerrar archs especiales.*/ 27076 

27077 int op; 

27078 

27079 op = mess_ptr->m_type; /* guardar DEV OPEN o DEV CLOSE p/después */ 

27080 mess_ptr->DEVICE = (mess_ptr->DEVICE » MINOR) & BYTE; 

27081 mess_ptr->PROC_NR = íp -íproc; 

27082 

27083 call_task(task_nr, mess_ptr); 

27084 

27085 /* Tarea acabó. Ver si llamada acabó. */ 

27086 if (mess_ptr->REP_STATUS = SUSPEND) { 

27087 if (op = DEV OPEN) tasknr = XPOPEN; 

27088 suspend(task_nr); /* suspender usuario */ 

27089 } 

27090 } 

27092 /*============================== = =================== = ===== === 

27093 * tty_open 

27094 *== ■ ■ ■ ■ : = ^ =============== =^^ =:======================= == 

27095 PUBLIC void tty_open(task_nr, mess_ptr) 

27096 int task_nr; 

27097 message *mess_ptr; 

27098 { 

27099 /* Se invoca desde la struct dmap en table.c al abrir una tty. */ 

27100 

27101 int r; 

27102 dev_tdev; 

27103 int flags, proc; 

27104 register struct fproc *rfp; 

27105 

27106 dev = (dev_t) mess_ptr->DEVICE; 

27107 flags = mes s_ptr->COUNT; 

27108 proc = fp -fproc; 

27109 

27110 /* Agregar 0_NOCTTY a las banderas si este proceso no es jefe 

27111 * de sesión, o si ya tiene una tty controladora, o si es la tty 

27112 * controladora de alguien más. 

27113 */ 

27114 if (!fp->^_sesldr 11 fp->fp_tty 1= 0) { 
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27115 flags 1 = ONOCTTYj 

27116 } else { 

27117 for (rfp = &fproc[LOW_USER]; rfp < &fproc[NR_PROCS]; rfp++) { 

27118 if (rfp->fp_tty = dev) flags 1= 0_N0CTTY; 

27119 } 

27120 } 

27121 

27122 r = dev_io(DEV_OPEN, mode, dev, (off_t) 0, flags, proc, NILPTR); 

27123 

27124 if (r = 1) { 

27125 fp->fp_tty = devj 

27126 r = OK; 

27127 } 

27128 

27129 mess_ptr->REP_STATU S = r; 

27130 } 

27133 7*=======================================================================* 

27134 * ctty_open * 

27135 *======================================================================*7 

27136 PUBLIC void ctty_open(task_nr, mess_ptr) 

27137 int task_nr; 

27138 message *mess_ptr; 

27139 { 

27140 7 * Este procedimiento se invoca desde la struct dmap en table.c al abrir 

27141 * Idev/tty, el disp mágico que traduce a la tty controladora. 

27142 *7 

27143 

27144 mess_ptr->REP_STATUS = fp->fp_tty == 0 ? ENXIO : OK; 

27145 } 

27148 7*======================================================================* 

27149 * ctty clase * 

27150 *==============================-========================================*71 

27151 PUBLIC void ctty_close(task_nr, mess_ptr) 1 

27152 inttasknr; 1 

27153 message *mess_ptrj 

27154 { 

27155 7 * Cerrar Idev/tty. *1 

27156 

27157 mess_ptr->REP_STATUS = OK; 

27158 } 

27161 7*=======================================================================* 

27162 * do_setsid * 

27163 *=======================================================================*7 

27164 PUBLIC int do_setsid() 

27165 { 

27166 7* Realizar lado de FS de la llamada SETSID, o sea, deshacerse de la terminal 

27167 * controladora de un proceso Y hacer a éste jefe de sesión. 

27168 *1 

27169 register struct fproc *rfp; 

27170 

27171 7 * Sólo el MM puede efectuar la llamada SETSID directamente. *7 

27172 if (who 1 = MM PROC NR) retum(ENOSYS); 

27173 

27174 7* Hacer al proceso jefe de sesión sin tty controladora. *1 
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27175 rfp = &fproc[slotl]; 

27176 rfp->fp_sesldr = TRUE; 

27177 rfp->fp_tty = 0; 

27178 } 

27181 /♦=- -= ============================= == ============================ 

27182 * dojoctl * 

27183 *======================================================== 

27184 PUBLIC int do_ioctl() 

27185 { 

2Z186 /* Ejecutar la llamada al sistema ioctl(ls_fd, request, argx) (usa fmto m2). */ 27187 

27188 struct filp *f; 

27189 register struct inode *rip; 

27190 dev_tdev; 

27191 

27192 if ((f = get_filp(ls_fd» == NIL_FILP) return(err_code); 

27193 rip = f->filp_inoj /* obtener apunt a nodo-i */ 

27194 if ( (rip->i_mode & ITYPE) 1= I CHAR SPECIAL 

27195 && (rip->i_mode & I TYPE) 1= I BLOCK SPECIAL) retum(ENOTTY); 

27196 dev = (dev_t) rip->i_zone[0]; 

27197 fmd_dev(dev); 

27198 

27199 dev_mess= m; 

27200 

27201 dev_mess.m_type = DEVJOCTL; 

27202 devmess.PROCNR = who; 

27203 devmess.TTYLINE = minar; 

27204 

27205 /* Invocar la tarea. */ 

27206 (*dmap[major] ,dmap_rw) (task, &dev_mess); 

27207 

27208 /* La tarea acabó. Ver si la llamada acabó. */ 

27209 if (dev mess.REP STATUS = SUSPEND) { 

27210 if (f->filp_flags & ONONBLOCK) { 

27211 /* No se supone que se bloquee. */ 

27212 dev_mess.m_type = CANCEL; 

27213 devmess.PROCNR = who; 

27214 dev_mess.TTY_LINE = minar; 

27215 (*dmap[major] ,dmap_rw) (task, &dev_mess); 

27216 if (dev_mess.REP_STATUS = EINTR) dev_mess.REP_STATUS = EAGAIN; 

27217 } else { 

27218 suspend(task); /* Debe suspenderse el usuario. */ 

27219 } 

27220 } 

27221 retum(dev_mess.REP_STATUS); 

27222 } 

27225 /*====================================================== == == = 

27226 * fmd_dev * 

27227 *===================================================== == ======= 

27228 PRIVATE void fmd_dev(dev) 

27229 dev_t dev; /* dispositivo */ 

27230 { 

27231 /* Extraer núm de disp principal y secundario del parámetro. */ 

27232 

27233 majar = (dev » MAJOR) & BYTE; /* núm dispositivo principal */ 

27234 minar = (dev » MINOR) & BYTE; /* núm dispositivo secund */ 


*/ 


*/ 
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27235 if (major >= max major) { 

27236 major = minor = 0; /* fallará con ENODEV *7 

27237 } 

27238 task = dmap[major] ,dmap_task; 7 * cuál tarea atiende dispositivo *7 

27239 } 

272427*=============================================================* 

27243 * call_task * 

27244 *=============================================================*7 

27245 PUBLIC void call_task(task_nr, mess_ptr) 

27246 int task_nrj; /* cuál tarea invocar *7 

27247 message *mess_ptr; /* apunt a mensaje p/tarea *7 

27248 { 

27249 7 * Joda E/S del FS se reduce a E/S de pares de dispositivo principal/secund. 

27250 * Estos conducen a llamadas de las rutinas sigtes vía tabla dmap. 

27251 */ 

27252 

27253 int r, proc_nr; 

27254 message local_m; 

27255 

27256 procnr = mess_ptr->PROC_NR; 

27257 

27258 while ((r = sendrec(task_nr, mess_ptr)) = ELOCKED) { 

27259 7 * sendrec() falló p/evitar bloqueo mortal. La tarea ’task_nr' 

27260 * está tratando de enviar mensaje REVIVE p/solicitud previa. 

27261 * Manejar e intentar otra vez. 

27262 *7 

27263 if ((r = receive(task_nr, &local_m)) != OK) break; 

27264 

27265 7 * Si tratamos de enviar mensaje de cancelar a una tarea que acaba de enviar 

27266 * respuesta de finalización, ignorar respuesta y abortar solicitud de 

27267 * cancelar. El invocador revivirá el proceso. 

27268 */ 

27269 if (mess_ptr->m_type == CANCEL && local m.REP PROC NR = proc nr) 

27270 retum; 

27271 

27272 7 * Si no, debe ser un REVIVE. *7 

27273 if (local_m.m_type 1= REVIVE) { 

27274 printf( 

27275 "fs: strange device reply from %d, type = %d, proc = %d\n", 

27276 local_m.m_source, 

27277 local_m.m_type, local_m.REP_PROC_NR); 

27278 continué; 

27279 } 

27280 

27281 revive (local_m. REP_PROC_NR, local_m.REP_STATUS); 

27282 } 

27283 

27284 7 * El mensaje recibido puede ser una respuesta a esta llamada, o un REVIVE 

27285 * para algún otro proceso. 

27286 *7 

27287 for (j;) { 

27288 if (r 1= OK) panic("call_task: can't send/receive", NO_NUM); 

27289 

27290 7 * El proc piel que hicimos sendrec(), ¿obtuvo resultado? *7 

27291 if (mess_ptr->REP_PROC_NR == proc_nr) break; 

27292 

27293 7 * Si no, debe ser un REVIVE. *7 

27294 if(mess_ptr->m_type != REVIVE) { 








27335 * no_dev 

27336 ♦=== = ========—= ========== == = = === 

27337 PUBLIC void no_dev(task_nr, m_ptr) 

27338 int task_nr; /* no se usa -p/compatib con dmap_t */ 

27339 message *m_ptr; /* apuntador a mensaje */ 

27340 { 

27341 /* No hay dispositivo ahí. */ 

27342 

27343 m_ptr->REP_STATUS = ENODEVj 

27344 } 
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27400 /* Este archivo contiene algunas rutinas de utilidad general. 

27401 * 

27402 * Los puntos d~ entrada a este archivo son 

27403 * clock_time: pedir el tiempo real a la tarea de reloj 

27404 * copy: copiar un bloque de datos 

27405 * fetch ñame: obtener nombre ruta de espacio de usuario 

27406 * no_sys: rechazar llamada al sistema que el FS no maneja 

27407 * panic: algo terrible ocurrió; MINEX no puede continuar 

27408 * conv2: intercambiar bytes en int de 16 bits 

27409 * conv4: intercambiar bytes en long de 32 bits 

27410 */ 

27411 

27412 #include "fs.h" 

27413 #include <minix/com.h> 

27414 #include <minix/boot.h> 

27415 #include <unistd.h> 

27416 #include "buf.h" 

27417 #include "file.h" 

27418 #include "fproc.h" 

27419 #include "inode.h" 

27420 #include "param.h" 

27421 

27422 PRIVATE int panicking; /* inhibe pánicos recursivos en sync */ 

27423 PRIVATE message clock mess; 

27424 

27425 /*= = ============================ == ===== == ========= 

27426 * clock_time 

27427 *=== == == = = = = == === = = = === = = = = = = == = = = ==== = = = = = == = 

27428 PUBLIC time_t clock_time() 

27429 { 

27430 /* Esta rutina devuelve el tiempo en segundos desde 1.1.1970. MINIX 

27431 * es un sistema astrofísicamente ignorante que supone que la Tierra 

27432 * gira con rapidez constante y que no existen los segundos bisiestos. 

27433 */ 

27434 

27435 register int k; 

27436 

27437 clock_mess.m_type = GETTIME; 

27438 if ( (k = sendrec(CLOCK, &clock_mess)) 1= OK) panic("clock_time err", k); 

27439 

27440 retum( (time_t) clock_mess.NEW_TIME); 

27441 } 

27444 /*================================ = ===== === ======== 

27445 * fetch ñame 

27446 *================== = ===== == -= == ====== = ======== 

27447 PUBLIC int fetch_name(path, len, flag) 

27448 char *path; /* apunt a mta en esp usuario */ 

27449 int len; /* longit mta, incl byte 0 */ 

27450 int flag; /* M3 implica mta quizá en mens */ 

27451 { 

27452 /* Obtener mta y colocarla en ’user_path'. 

27453 * Si 'flag' = M3 Y ’len’ <= M3STRING, la mta está presente 

27454 * en 'message'. Si no, copiarla del espacio de usuario. 
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27455 */ 

27456 

27457 register char *rpu, *rpm; 

27458 int r; 

27459 

27460 /* Verificar que la longitud del nombre sea válida. */ 

27461 if (len <= 0) { 

27462 err_code = EINVAL; 

27463 retum(EGENERIC); 

27464 } 

27465 

27466 if (len > PATHMAX) { 

27467 errcode = ENAMETOOLONG; 

27468 retum(EGENERIC); 

27469 } 

27470 

27471 if (flag = M3 && len <= M3 STRING) { 

27472 /* Sólo copiar ruta del mensaje a 'user_path'. */ 

27473 rpu = &user_path[0]; 

27474 rpm = pathname; /* contenida en mensaje entrada */ 

27475 do { *rpu++ = *rpm++; } while (—len); 

27476 r = OK; 

27477 } else { 

27478 /* Cadena no contenida en el mensaje. Obtener de espacio usuario. */ 

27479 r = sys_copy(who, D, (phys_bytes) path, 

27480 FSPROCNR, D, (phys_bytes) user_path, (phys_bytes) len); 

27481 } 

27482 retum(r); 

27483 } 

27486 /* = = = =========================== == ================= = ======== == * 

27487 * no_sys * 

27488 *========================= — ======= === ============== == ==*/ 

27489 PUBLIC int no_sys() 

27490 { 

27491 /* Alguien usó un número de llamada al sistema ilegal. */ 

27492 

27493 retum(EINVAL); 

27494 } 

27497 /*== = ===== = ======================== = ======================= = =* 

27498 * panic * 

27499 ' 

27500 

27501 

27502 

27503 

27504 

27505 

27506 

27507 

27508 

27509 

27510 

27511 

27512 

27513 

27514 


PUBLIC void panic(format, num) 

char *format; /* cadena de formato */ 

int num; /* núm para cadena de formato */ 

{ 

/* Algo terrible sucedió. Ocurren pánicos cuando se detecta una inconsistencia 

* intema, p. ej., un error de programación o un valor no permitido 

* de una constante definida. 


if (panicking) retum; /* no pánico durante sync */ 

panicking = TRUE; /* evitar otro pánico durante sync */ 

printf("File system panic: %s ", format); 
if (num 1= NO_NUM) printf("%d",num); 
printf("\n"); 

(void) do syncQ; 


/* vaciar todo al disco */ 
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27515 sysabort(RBTPANIC); 

27516 } 

275197*=============================================================* 

27520 * conv2 * 

27521*=============================================================*7 

27522 PUBLIC unsigned conv2(norm, w) 

27523 int norm; 7 * TRUE si no intercambio de bytes *7 

27524 int W; 7* promoción de pal 16 bits por interc *1 

27525 { 

27526 7 * Quizá intercambiar palabra de 16 bits entre orden de bytes 8086 y 68000. *7 27527 

27528 if (norm) retum( (unsigned) W & OxFFFF); 

27529 retum( ((w&BYTE) « 8) I ( (w»8) & BYTE»; 

27530 } 

275337*=============================================================* 

27534 * conv4 * 

27535 *============================================================*7 

27536 PUBLIC long conv4(norm, x) 

27537 int norm; 7 * TRUE si no intercambio de bytes *7 

27538 long X; 7* long de 32 bits por intercambiar *7 

27539 { 

27540 7 * Quizá intercambiar long de 32 bits entre orden de bytes 8086 y 68000. *7 

27541 

27542 unsigned lo, hi; 

27543 long 1; 

27544 

27545 if (norm) retum(x); 7 * orden bytes ya estaba ok *7 

27546 lo = conv2(FALSE, (int) x & OxFFFF); 7 * mitad orden bajo, intercamb *7 

27547 hi = conv2(FALSE, (int) (x»16) & OxFFFF); 7 * mitad orden alto, interc *7 

27548 1 =((long)lo«16)Ihi; 

27549 retum(l); 

27550 } 


src/fs/putk.c 


27600 7 * A veces el FS debe exhibir mensajes. Usa la rutina estándar de biblioteca 

27601 * printk(). (El nombre "printf' realmente es una maGro definida como "printk"). 

27602 * Se exhibe invocando la tarea TTY directamente, no a través de FS. 

27603 *7 

27604 

27605 #include "fs.h" 

27606 #include <minix/com.h> 

27607 

27608 #define BUF SIZE 100 7 * exhibir tamaño de buffer *7 

27609 

27610 PRIVATE int buf_count; /*# caracteres en buffer *7 

27611 PRIVATE char print bufjBUF SIZE]; 7 * buffer de salida aquí *7 

27612 PRIVATE message putch_msg; 7* sirve para mensaje a tarea TTY *7 

27613 

27614 FORWARD _PROTOTYPE( void flush, (void) 
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27615 

27616 /*======================= = ====== = ==== 

27617 * putk 

27618 ♦===================== == == = ======== 

27619 PUBLIC void putk(c) 

27620 int c; 

27621 { 

27622 /* Acumular otro carácter. Si 0 o buffer lleno, exhibirlo. */ 

27623 

27624 if (c == 0 11 buf_count = BUF SIZE) flush(); 

27625 if (c = '\n') putk( V); 

27626 if (c != 0) print_buf[buf_count++] = c; 

27627 } 

27630 /*= = ===================== = ====== = === 

27631 * flush 

27632 *======================================= 

27633 PRIVATE void flush() 

27634 { 

27635 /* Vaciar el buffer de impresión invocando la tarea TTY. */ 

27636 

27637 

27638 if (buf_count = 0) retum; 

27639 putchmsg.mtype = DEVWRITE; 

27640 putchmsg.PROCNR = 1; 

27641 putchmsg.TTYLINE = 0; 

27642 putch_msg.ADDRESS = print_buf; 

27643 putch_msg.COUNT = buf_count; 

27644 call_task(TTY, &putch_msg); 

27645 buf_count = 0; 

27646 } 


,/end of list 
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Directorio inelude 

01400 a.out.h 
00000 ansi.h 
00200 ermo.h 
00900 fcntl.h 
04100 ibm/partition.h 
00100 limits.h 
03700 minix/boot.h 
03400 minix/callnr.h 
03500 minix/com.h 
02600 minix/config.h 
02900 minix/const.h 
03800 minix/keymap.h 
04000 minix/partition.h 
03300 minix/syslib.h 
03100 minix/type.h 
00700 signal.h 
01000 stdlib.h 
00600 string.h 
02400 sys/dir.h 
01800 sys/ioctl.h 
02200 sys/ptrace.h 
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02000 sys/sigcontext.h 
02300 sys/stat.h 
01600 sys/types.h 
02500 sys/wait.h 
01100 termios.h 
00400 unistd.h 

Kernel 

05500 asserth 
10100 at wini.c 
11000 clock.c 
13600 console.c 
04300 const.h 
14600 dmp.c 
09100 driver.c 
09000 driver.h 
09500 drvlib.c 
09400 drvlib.h 
07500 exception.c 
05000 glO.h 
07600 Í8259.C 
04200 kemel.h 
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13000 keyboard.c 

Sistema de archivi 

08000 klib.s 

20100 buf.h 

08100 klib386.s 

21000 cache.c 

06700 main.c 

19500 const.h 

09700 memory.c 

20200 dev.h 

08800 misc.c 

27000 device.c 

05800 mpx.s 

20300 file.h 

05900 mpx386.s 

22200 filedes.c 

06900 proc.c 

20000 fproc.h 

05100 proc.h 

19400 fs.h 

07700 protect.c 

19900 glO.h 

05200 protect.h 

21500 inode.c 

04700 proto.h 

20500 inode.h 

05400 sconst.h 

25400 link.c 

06500 start.c 

22300 lock.c 

14700 system.c 

20400 lock.h 

05600 table.c 

22500 main.c 

11700 tty.c 

26600 misc.c 

11600 tty.h 

25100 mount.c 

04500 type.h 

22900 open.c 

10000 wini.c 

20600 param.h 
24700 path.c 

Administrador de memoria 

24300 pipe.c 

18800 alloc.c 

26100 protectx 

17600 break.c 

19700 proto.h 

15900 const.h 

27600 putk.c 

17100 exec.c 

23400 read.c 

16800 forkexit.c 

25900 stadir.c 

18500 getset.c 

21900 super.c 

16200 glO.h 

20700 super.h 

16600 main.c 

20800 table.c 

15800 mm.b 

26400 time.c 

16300 mproc.h 

19600 type.h 

16400 param.h 

27400 utility.c 

16100 proto.h 

19300 putk.c 

17800 signal.c 

16500 table.c 

18600 trace.c 

16000 type.h 

19100 utility.c 

24000 write.c 
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A8S 

ACCESS 

ACCESSED 

ACTIVEFLAG 

ADDRESS 

ADDWN 

AEND 

AF1 

AF10 

AF11 

AF12 

AF 

AF 

AF4 

AF5 

AF6 

AF 

AF 

AF9 

AHOM 

AINSRT 

ALAR M 

ALAAMON 

ALEF 


3806 #defme 
2975 #define 
3432 #define 
5289 #defme 


APGDN 
APGUP 
APLUS 
ARGMAX 
4117 #defíne ARG MA 
3653 #define ARIGHT 


3839 #defme 
3838 #defme 
3842 #define 
162 #defme 


3835 #defme 
3833 #defme 
3879 #defme 

3888 #define 

3889 #define 
3890 #defm 

3880 #defme 

3881 #defme 

3882 #defme 

3883 #defme 

3884 #defme 

3885 #defme 

3886 #defme 

3887 #define 
3832 #defme 
3843 #defme 

3428 #defme 
16348 #define 
3836 #define 


ATIRQO 

ALLOW GAP MES 2665 #defme AT IAQl 
ALLMODES 2986#defme ATWINI IRQ 


ALT 

AMID 

AMIGA 

ANMI 

ANY 


3813 #defme 
3840 #defme 
2622 #defme 
3841 #defme 
3504 #defme 


AUDIO 
AUDIOSTACK 
AUP 

AUTOBIOS 

AVL 


AVL 286 TSS 
ABLR 
ADATAPDS 
ADRELPDS 
164 #defme A_EXEC 
3837 #defme A HASEXT 


ASF1 

ASF10 

ASF11 

ASF12 

ASF2 

ASF3 

ASF4 

ASF5 

ASF6 

ASF7 

ASF8 

ASF9 

ASKDEV 

ASSERTH 

ATARI 

ATARITYPE 

ATAIDENTIFY 

ATIME 


3921 #define 

3930 #define 

3931 #defme 

3932 #defme 

3922 #defme 

3923 #define 

3924 #defme 

3925 #defme 


AHASLNS 

AHASRELS 

AHASTOFF 

AJ80386 

AI8086 

A_M68K 

AMAGICO 

AMAGICl 


3926 #define A MINHDR 

3927 #define A_NONE 


2784 #define 
5504 #defme 
2621 #defme 
2700 #defme 


APAL 

APURE 

ASEP 

ASPARC 


10164 #defme AS YMPOS 
19550 #defme A TEXTPOS 

10173 #defme A TOVLY 

10174 #define ATRELPOS 

4365 #define A_UZP 
3577 #define A WLR 
5667 #defme B0 

3834 #defíne B110 

2663 #defme B115200 

5325 #defíne B1200 


5292 #define 

1438 #defme 

1453 #defme 

1459 #defme 

1445 #defme 

1455 #defme 

1456 #defme 

1454 #defme 

1457 #defme 

1435 #define 
1432 #defme 

1433 #define 

1426 #defme 

1427 #defme 

1451 #defme 
1431 #define 

1434 #define 
1444 #defme 
1443 #define 

1447 #defme 

1446 #defme 

1436 #defme 

1460 #define 

1452 #defme 

1448 #defme 

1458 #defme 
1442 #defme 

1439 #defme 
1185 #defme 
1188 #defíne 
1266 #defme 
1194 #defme 
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B134 11B9 ffdefme 

B150 1190 #define 

81800 1195 #define 

819200 1199 #define 

8200 1191 #define 

B2400 '1196 #define 

B300 1192 #define 

B38400 1200 #defme 

B4800 1197 #define 

B50 1186 #define 

B57600 1265 #defme 

B600 1193 #define 

B75 11B7 #define 

B9600 1198 #define 

BADMAG 142B #defme 

BASE HIGH SHI 5311 #define 
BASE MIDDLE S 5274 #define 
BEEP FAEQ 13649 #defme 

BEG PAOC ADDA 5163#defme 
BEG SEAV ADDA 5166 #define 
F1EG USEA ADDA 5167 #define 
BIG 5324 #defme 

BIOS_IAQ0_VEC 4349 #defme 
BIOS IAQBVEC 4350 #defme 
BIOS VECTOA 4368 #define 
BITCHUNK BITS 21920 #defme 
B1TMAP CHUNKS 19567 #defme 
BITS PEA BLOC 21921 #defme 
BLANK COLOA 13632 #defme 
BLANK MEM 13635 #defme 
BLOCKS MINIMU 23820 #defme 
BLOCK SIZE 2915 #define 

BMS 2715 #define 

BOOT BLOCK 19560 #define 
BOOT TICKS 3884 #defme 

BOTH 3503 #defme 

BOUNDS VECTOA 5250 #define 
BAEAKPOINT VE 4337 #define 
BAK 3418 #define 

BAKINT 1124 #defme 

BUFEXTAA 9132 #defme 

BUF SIZE 27608 #defme 

BUF SIZE 19309 #defme 

BUSY_286_TSS 5294 #define 

BYTE 2941 #defme 

BYTE GAAN MAX 5312#defme 
BYTE SWAP 19554 #defme 

BTIME 13650 #defme 

C 3805 #define 

CA 3807 #define 

CALL 286 GATE 5295 #defme 

CALOCK 3860 #defme 

CANCEL 3519 #define 

CASCADEJAQ 4358 #defme 

CBHD 2717 #defme 

CDIOEJECT 1911 #define 

CDIOPAUSE 1909 #defme 

CDIOPLAYMSS 1904 #define 
CDIOPLAYTI 1903 #defme 

CDIOAEADSUBCH 1907 #defme 
CDIOAEADTOC 1906 #defme 


CDIOAEADTDCHD 1905 #define 
CDIOAESUME 1910 #defme 

CDIOSTOP 1908 #define 

CDOWN 3849 #defme 

CDAOM 3574 #defme 

CDAOM_STACK 5666 #defme 

CENO 3847 #defme 

CF1 3893 #define 

CF10 3902 #defme 

CF11 3903 #define 

CF12 3904 #defme 

CF2 3894 #define 

CF3 3895 #define 

CF4 3896 #define 

CF5 3897 #define 

CF6 3898 #defme 

CF7 38991/define 

CFB 3900 #define 

CF9 3901 #defme 

CHAA BIT 109 #define 

CHAA MAX 111 #defme 

CHAA MIN 110 #define 

CHOIA 3413 #define 

CHILD MAX 166 #defme 

CHILD STIME 3683 #define 

CHILD UT1ME 3682 #defme 

CHIP 2778 #define 

CHIP 2773 #defme 

CHIP 2763 #defme 

CHMOD 3416 #define 

CHOME 3846 #define 

CHOWN 3417 #define 

CHAOOT 3448 #defme 

CINSAT 3857 #define 

CLEAN 19548 #define 

CLEFT 3850 #define 

CLICK SHIFT 2959 #defme 

CLICK SHIFT 2964 #defme 

CLICK SIZE 2963 #defme 

CLICK SIZE 2958 #defme 

CLOCAL 1140 #define 

CLOCK 3602 #define 

CLOCKACKBIT 11064 #define 
CLOCK INT 3610 #define 

CLOCK_IAQ 4356 #defme 

CLOCK PAOC NA 3644 #defme 
CLOCK STACK 5672 #define 

GLOSE 3407 #define 

CMDDIAG 10162 #define 

CMDFOAMAT 10160 #defme 

CMD IDLE 10155 #define 

CMD AEAD 10157 #defme 

CMD AEADVEAIF 10159 #define 
CMD AECALIBAA 10156 #define 
CMD SEEK 10161 #define 

CMD SPECIFY 10163 #define 

CMD WAITE 10158 #defme 

CMID 3854 #define 

CNMIN 3855 #define 

COLOA_BASE 13628 #defme 

COLOASIZE 13630 #define 


CONFOAMING 5284 #define 

CONSOLE 13037 #define 

CONS MINOA 11760 #define 
CONS AAM WOAD 13636 #defme 
COPAOC_EAA_VE 5304 #defme 
COPAOC NOT VE 5252 #define 
COPAOC SEG VE 5254 #defme 
COPY BYTES 3677 #define 

COAE MODE 17832 #define 

COUNT 3650 #define 

COUNTEA_FAEQ 11057 #defme 
CPGDN 3853 #define 

CPGUP 3852 #define 

CPLUS 3856 #define 

CPVEC_NA 2922 #define 

CAEAD 1141 #define 

CAEAT 3409 #define 

CA1GHT 3851 #defme 

CS5 1143 #define 

CS6 1144 #define 

CS7 1145 #define 

CS8 1146 #define 

CSIZE 1142 #defme 

CSTOPB 1147 #define 

CSJNDEX 5213 #define 

CS LDT INDEX 5239 #define 

CS SELECTOA 5229 #defme 

CTIME 19551 #define 

CTL EIGHTHEAD 10166 #define 

CTL INTDISABL 10170 #define 

CTL_NOECC 10167 #define 

CTL NOAETAY 10166 #defme 

CTL AESET 10169 #define 

CTAL 3811 #defme 

CUP 3848 #define 

CUASOA 13646 #define 

C 6845 13641 #define 

C EXT 1506 #defme 

C NULL 1505 #define 

C STAT 1507 #define 

CopyMess 6932 #define 

O 2928 #define 

DATA 13644 #define 

DATA CHANGED 17622 #defme 

DEAF 10209 #define 

DEBUG VECTOA 4335 #define 

DEFAULT 5323 #define 

DELETE 19545 #defme 

DELTA_TICKS 3641 #define 

DEL SCAN 13036 #define 

DESC 386 BIT 5318#define 

DESC ACCESS 5267 #define 

DESC BASE 5265 #define 

DESC 8ASE HIG 5308 #define 

DESCBASE_M1D 5266 #define 

DESC GAANULAA 5307 #define 

DESC_SIZE 5268 #define 

DEVICE 3648 #define 

DEV CLOSE 3525 #define 

DEV FDO 3714 #define 

DEV HDO 3715 #define 
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DEV IDCTL 3523 #define 

DEV OPEN 3524 #define 

DEV PER DRIVE 9419 #defme 

DEV RAM 37,16 #defme 

DEV READ 3521 #defme 

DEV SCSI 3717 #defme 

DEV WRITE 3522 #defme 

DIOCEJECT 1863 #define 

DIOCGETP 1885 #define 

DIOCSETP 1884 #define 

DIRBLKSIZ 2405 #defme 

DIRECTORY BLO 20161 #defme 
DIRSIZ 2408 #defme 

DIRTY 19549 #define 

DIR ENTRY SIZ 19563 #defme 
DIVIDE_VECTOR 4334 #define 
DL ADDR 3553 #defme 

DL BROAD REQ 3565 #define 
DL CLCK 3552 #defme 

DLCOUNT 3550 #defme 

DL ETH 3532 #defme 

DLJGETSTAT 3542 #defme 

DL INIT 3540 #defme 

DL INIT REPLY 3545 #defme 
DL MODE 3551 #defme 

DLMULTI REQ 3564 #defme 
DL NOMODE 3562 #defme 
DL PACK RECV 3558 #defme 
DL PACK SEND 3557 #defme 
DL PORT 3548 #defme 

DL PROC 3549 #defme 

DL PROMISC RE 3563 #define 
DL READ 3538 #defme 

DL READV 3539 #defme 

DL READ IP 3559 #defme 
DL STAT 3554 #defme 

DL STOP 3541 #defme 

DL TASK REPLY 3546 #defme 
DLWRITL 3536 #defme 

DL WRITEV 3537 #define 

DMA BUF_SIZE 9055 #define 
DMA SECTORS 2682 #defme 
DONTSWAP 19555 #~fme 
DOUBLE FAULT- 5253 #defme 
DOWN 3821 #defme 

DP8390 STACK 5642 #defme 
DPL 5278 #defme 

DPL SHIFT 5279 #defme 

DPETH0 INDEX 5219 #define 
DP ETH0_SELEC 5235 #define 
DP ETH 1 INDEX 5220 #defme 
DP ETH1 SELEC 5236 #defme 
DSPIOBITS 1917 #defme 
DSPIOMAX 1919 #defme 
DSPIORATE 1914 #define 
DSPIORESET 1920 #defme 
DSPIOSIGN 1918 #defme 
DSPIOSIZE 1916 #defme 
DSPIOSTEREO 1915#define 
DST BUFFER 3676 #defme 
DST PROC NR 3675 #defme 


DSTSPACE 3674 #define 

DS_266 INDEX 5216 #define 

DS_286_SELECT 5232 #defme 

DS INDEX 5210 #defme 

DS LDT INDEX 5240 #defme 

DS SELECTOR 5225 #defme 

DT 20900 #defme 

DUMPED 17B33 #defme 

DUMP_SIZE 17834 #defme 

DUP 3438 #define 

DUP MAX 19541 #defme 

E2BIG 242 #defíne 

EACCES 248 #defme 

EADDRINUSE 265 #define 

EAGAIN 246 #defme 

EBADCALL 297 #defme 

E8ADDEST 262 #define 

EBADF 244 #defme 

EBADIOCTL 279 #defme 

EBADMODE 280 #defme 

EBUSY 251 #defme 

ECHILD 245 #defme 

ECHO 1153 #define 

ECHOE 1154#define 

ECHOK 1155 #define 

ECHONL 1156 #define 

ECONNREFUSED 286 #defme 
ECONNRESET 287 #defme 

EDEADLK 270 #define 

EDOM 268 #define 

EDSTNOTRCH 283 #defme 

EEXIST 252 #defme 

EFAULT 249 #defme 

EFBIG 262 #defme 

EGA 13642 #defme 

EGA ST ZE 13631 #defme 

EGENERIC 235 #defme 

EICKMANN 2718 #defme 

EINTR 239 #defme 

EINVAL 257 #defme 

EIO 240 #defme 

EISCONN 284 #define 

EISDIR 256 #defme 

ELOCKED 296 #defme 

EMFILE 259 #defme 

EMLINK 266 #define 

EM BASE 8813 #defíne 

ENABLE 4384 #define 

ENABLEADAPTE 2677 #define 
ENA8LE_AT WIN 2673 #defme 
ENABLE AUDIO 2769 #defme 
ENABLE BINCOM 2685 #defme 
ENABLE BIOS W 2674 #defme 
ENABLE CACHE2 2669 #defme 
ENABLE CDROM 2768 #defme 
ENABLE ESDI_W 2675 #define 
ENABLE MITSUM 2 678 #define 
ENABLE NETWOR 2672 #defme 
ENABLE SB AUD 2679 #define 
ENABLE SCSI 2767 #defme 

ENABLE SRCCOM 2686 #defme 


ENABLE WINI 2765 #defme 

ENABLE XT WIN 2676 #defme 

ENAMETOOLONG 271 #defme 

END 3819 #defme 

END OF FILE 19557 #defme 

END PROC ADDR 5164 #define 

END TASK ADDR 5165 #defme 

END TTY 11771 #defme 

ENFILE 258 #defme 

ENOCONN 293 #defme 

ENODEV 254 #defme 

ENOENT 237 #defme 

ENOEXEC 243 #define 

ENOLCK 272 #defme 

ENOMEM 247 #defme 

ENOSPC 263 #define 

ENOSYS 273 #defme 

ENOT8LK 250 #defme 

ENOTCONN 291 #defme 

ENOTDIR 255 #defme 

ENOTEMPTY 274 #defme 

ENOTTY 260 #defme 

ENOURG 290 #define 

ENTER 19544 #defme 

ENXIO 241 #defme 

EOUTOFBUFS 278 #defme 

EPACKSIZE 277 #defme 

EPERM 236 #define 

EPIPE 267 #define 

EPOFF 4434 #defme 

EP ON 4435 #defme 

EP SET 4436 #defme 

EP UNSET 4433 #defme 

ERANGE 269 #defme 

EROFS 265 #defme 

ERR 10189 #defme 

ERROR AC 10149 #defme 

ERROR B 8 10146 #defme 

ERROR DM 10151 #defme 

ERROR ECC 10147 #define 

ERROR ID 10148 #defme 

ERROR TK 10150 #defme 

ERR BAD SECTO 10190 #define 

ESC 11606#defme 

ESCAPED 11674 #define 

ESC_SCAN 13033 #defme 

ESHUTDOWN 292 #defme 

ESPIPE 264 #define 

ESRCH 238 #define 

ES_286JNDEX 5217 #defme 

ES_286_SELECT 5233 #define 

ESINDEX 5211 #defíne 

ES SELECTOR 5226 #defme 

ETHER IRQ 4359 #defme 

ETIMEDOUT 288 #defme 

ETXTBSY 261 #defme 

EURG 289 #defme 

EWOULDBLOCK 281 #define 

EXDEV 253 #define 

EXEC 3446 #defme 

EXECUTABLE 5283 #define 
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EXIT 3402 #define F RDLCK 

EXIT FAILURE 1008 #define F SETFD 

EXIT SUCCESS 1009 #defme F SETFL 

EXPAND DOWN 5285 #define F SETLK 

EXT 3810 #define F_SETLKw 

EXTKEY 3814 #define F UNLCK 

EXTPART 4125 lidefme F WRLCK 

E BAD ADDR 310#define GA FONT SIZE 

E8AD8UF 305 #defme GA GRAPHICS D 

E BAD DEST 301 #defme GA GRAPHICS I 

E 8AD FCN 309 #defme GA SEQUENCER 

E BAD PROC 311 #define GA_SEQUENCER- 

E BAD SRC 302 #defme GA VIDEO ADDR 

E NO MESSAGE 307 #defme GDT INDEX 

E NO PERM 308 #defme GDT SELECTOR 

E 0VERRUN 304 #defme GDT SIZE 

E TASK 306 #defme GETGID 

E TRY_AGAIN 303 #defme GETPGRP 

F1 3865 #defme GETPID 

FIO 3874 #define GETUID 

Fll 3875 #define GET TIME 

F12 3876 #define GET UPTIME 

F2 3866 #define GRANULAR 

F3 3867 #defme GRANULARITY S 

F4 3868 #define HANGING 

F5 3869 #define HARDWARE 

F6 3870 #define HARDWARE STAC 

F7 3871 #define HARDINT 

F8 3872 #defme HASCAPS 

F9 3873 #defme HASH MASK 

FALSE 2912 #define HAVE_SCATTERE 

FASTLOAD 2785 #defme HCLICK SHIFT 

FAST DISK 2728 #defme HCLICKSIZE 

FCNTL 3445 #define HD CLOCK 

FD CLOEXEC 923 #defme HIGHEST ZONE 

FDMASK 23423 #defme HOME 

FILP CLOSED 20312 #define HOME_SCAN 

FIRST LDT IND 5221 #defme HUPCL 

FIRST TTY 11770 #define HZ 

FLAT DS_SELEC 5227 #defme IBM PC 

FLOPPY 3593 #defme ICANON 

FLOPPY IRQ 4363 #defme ICD 

FLOP STACK 5670 #define ICRNL 

F 3403 #define ICW1 AT 

FORWARD 2909 #defme ICW1 PC 

FPP 2789 #define ICW1PS 

FP FORMAT 2779 #defme ICW4 AT 

FP FORMAT 2795 #defme ICW4 PC 

FP IEEE 2760 #defme IDLE 

FP NONE 2759 #defme IDLE STACK 

FSTAT 3429 #defme IDLE STACK 

FSTRUCOPY 4415 #defme IDT INDEX 

FS PROC NR 2933 #defme IDT SELECTOR 

FULL_DATA_BLO 20165 #define IDT SIZE 

FUNC 3692 #defme IEXTEN 

FUNC TO CALL 3642 #defme IF MASK 

F DUPFD 913 #defme IGNBRK 

F-GETFD 914 #defme IGNCR 

F GETFL 916 #define IGNPAR 

F GETLK 918 #define IMAGE_DEV 

F OK 417 #defme IMAP 


E SÍMBOLOS 

926 #define INDEX 13643 #defme 

915 #defme INDIRECT 8LOC 20162 #define 

917 #define INET PROC NR 2934#defme 

919 #defme INITIALIZED 10208 #defme 

920 #define INIT ASSERT 5519#defme 

928 #defme INIT ASSERT 5508 #defme 

927 #defme INIT PID 15915 #defme 

13658 #defme INIT PROC NR 2935 #defme 

13656 #defme INIT PSW 4306#defme 

3655 #define INIT SP 4321 #defme 

13654 #define INIT_TASK_PSW 4307 #defme 

13653 #define INLCR 1129#defme 

13657 #defme INODE_8LOCK 20160 #defme 

5208 #defme INPCK 1130#defme 

5223 #defme INSRT 3829 #defme 

5203 #define INT2_CTL 4380 #defme 

3442 #define INT2 CTLMASK 4381 #defme 

3450 #defme INTEL 2754 #defme 

3421 #define INTR PRrvILEG 5243 #defme 

3425 #defme INT 286 GATE 5297 #define 

3604 #define INT CTL 4378 #define 

3606 #defme INT CTLMASK 4379 #defme 

5322 #defme INT GATE TYPE 7709 #defme 

5313 #defme INT MAX 125 #defme 

16346 #defme INTMAX 131 #define 

3638 #define INT MIN 124#defme 

5674 #define INTMIN 130#defme 

3520 #defme INVAL OP VECT 5251 #defme 

3815 #define INVAL_TSS_VEC 5255 #defme 

20168 #define IN CHAR 11679 #defme 

2946 #define IN_EOF 11683 #defme 

4323 #define IN EOT 11682#defme 

4324 #defme IN_ESC 11684 #defme 

2742 #define IN_LEN 11680#defme 

2995 #define IN LSHIFT 11681 #define 

3818 #define IN_USE 16344 #defme 

13035 #define IOCTL 3444 #defme 

1148 #define IOPL MASK 14810 #define 

2914 #define IP PTR 3695 #define 

2618 #define IRQO VECTOR 4351 #defme 

1157 #defme IRQ8 VECTOR 4352 #defme 

2716 #define ISEEK 2 0544 #defme 

1125 #define ISIG 1159 #define 

7608 #define ISTRIP 1131 #defme 

7609 #defme IS EMPTY 19546 #define 

7610 #define IXANY 1248#defme 

7611 #defme IXOFF 1132 #define 

7612 #defme IXON 1133#defme 

3589 #define I_8LOCK_SPECI 2980 #defme 

5645 #defme I CHAR SPECIA 2982 #defme 

5647 #define I DIRECTORY 2981 #defme 

5209 #defme I MOUNT 20542 #defme 

5224 #defme I_NAMED PIPE 2983 #defme 

5204 #define INOTALLOC 2991 #defme 

1158 #defme I_PIPE 20540 #defme 

4809 #defme I REGULAR 2979 #define 

1126 #define I SET GID BIT 2985 #defme 

1127 #define I SET UID BIT 2984 #defme 

1128 #define I TYPE 2978 #defme 

3709 #define K8IT 13030 #defme 

20748 #define KB ACK 13025 #defme 
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KB BUSY 13026 #defme MAXSECS 10200 #defme NIL PTR 2945 #defme 

KB COMMANO 13020 #defme MAX SECS 10198 #defme NIL SUPER 20747 #define 

KB GATE_A20 13021 #define MAYBE WRITEI 2800 #defme NKT 5742 #defme 

KB_IN_BYTES 13042 #defme MAYBE WRITE I 2802 #defme NLEN 14999 #defme 

KB_PULSE_OUTP 13022 #define MB CURJMAX 1011#defme NLOCK 3861 #define 

KB RESET 13023 #defme MB T ,F, N_MAX 115#defme NMIN 3827 #defme 

KB STATUS 13024 #defme MEM 3595 #defme NMI VECTOR 4336#define 

KEYBO 13017 #define MEMCHECK AOR 1 3038 #defme NOFLSH 1160#define 

KEYBOARO 2709 #defme MEMCHECK MAG 1 3039 #defme NORMAL 19530 #defme 

KEYBOARO IRQ 4357 #defme MEM BYTES 4412#defme NOT_ESCAPEO 11673 #defme 

KEY MAGIC 3939 #define MEM_DEV 3598 #defme NOT REVIVING 20031 #defme 

kILL 3434 #defme MEM PTR 3693 #defme NOT SUSPENDED 20029 #defme 

KIOCSMAP 1888 #define MEM STACK 5671 #define NO BIT 19539 #defme 

KMEM DEV 3599 #defme MESS_SIZE 3226 #defme NO BLOCK 2999 #defme 

KSIG 3453 #defme MID 3826#defme NOOFV 3002 #defme 

K_STACK_BYTES 4400 #define MILLISEC 11053 #define NO ENTRY 3000 #defme 

K STACK BYTES 4304 #define MIN 2950#define NO MAP 5155#defme 

L 3808 #define MINIX PART 4122 #defme NO MEM 15902 #define 

LAST FEW 16823 #defme MINOR 2919#define NO MOUNT 20541 #defme 

LATCH COUNT 11058#defme MINORJdOa 9421 #define NOJSÍUM 2944 #defme 

LDH DEFAULT 10131 #defme MINORJidla 9420 #defme NO PART 4123 #defme 

LDH LBA 10132 #defme MIOCGPSINFO 1893#defme NO_PIPE 20539 #defme 

LDT 5293 #defme MIOCRAMSIZE 1891 #defme NO READ 19531 #defme 

LIYT SIZE 5205 #defme MIOCSPSINFO 1892#defme NO SEEK 20543 #defme 

LED COOE 13027 #define MIXER 3578 #define NO_ZONE 3001 #define 

LEFT 3822 #define MIXER STACK 5668 #defme NQ 4429 #defme 

LEVELO VECTOR 4343 #define MIXIOGETINPUT 1925 #defme NQ 4427 #define 

LFLUSHO 1257 #define MIXIOGETINPUT 1924#defme NR_ACSI_ORIVE 2721 #defme 

LIMIT HIGH 5326 #defme MIXIOGETOUTPU 1926#defme NR BUFS 2643 #defme 

LINEWRAP 2664 #defme MIXIOGETVOLUM 1923 #defme NR BUFS 2648 #defme 

LINK 3410 #define MIXIOSETINPUT 1928#define NR BUFS 2653 #defme 

LINK MAX 168 #define MIXIOSETINPUT 1929#defme NR BUFS 2658 #defme 

LOG MINOR 11761 #defme MIXIOSETOUTPU 1930#defme NR_BUF HASH 2659 #defme 

LONG MAX 137 #defme MIXIOSETVOLUM 1927#defme NR BUF HASH 2654#defme 

LONG MIN 136 #define MKOIR 3436 #define NR BUF HASH 2649 #define 

LOOK UP 19543 #defme MKNOD 3415#defme NR BUF HASH 2644#defme 

LOW USER 2937 #define MM PROC NR 2932 #defme NR CONS 2694#define 

LSEEK 3420 #define MONO BASE 13627 #defme NR DLVICCS 10203 #defme 

MI 3123 #defíne MONO SIZE 13629 #define NR DIR ENTRIE 19564 #define 

M3 3124 #define MON CS INDEX 5214#defme NR FD DRIVES 2736 #defme 

M3 STRING 3126 #define MON CS_SELECT 5230 #defme NR FILPS 19506 #defme 

M4 3125 #define MOUNT 3422 #defme NR HOLES 18820 #defme 

M68000 2755 #define MTIME 19552 #define NR INODES 19507 #defme 

MACHINE 2616 #define MTIOCGET 1897#defme NR IOREQS 2923 #defme 

MACINTOSH 2623 #define MTIOCTOP 1896#defme NR IRQ VECTOR 4355 #defme 

MAJOR 2918 #defme M_6845 13640 #define NRJXDCKS 19509 #define 

MAP BLOCK 20163 #defme NAME MAX 171#defme NR MEMS 4387 #define 

MAP COLS 3934 #define ÑAME PTR 3694#defme NR MEMS 4403 #defme 

MAX 2949 #define NCALLS 3400#defme NR PARTITIONS 4118#defme 

MAX 286 SEG S 5271 #defme NCCS 1109#defme NR^PROCS 639 #defme 

MAX BLOCK NR 2994 #defme NEW TIME 3643#defme NR PTYS 2696 #defme 

MAX CANON 169 #define NGROUPS MAX 160#defme NR RAMS 9719#defme 

MAX DRIVES 10196 #defme NIL BUF 20139 #defme NR REGS 4406 #defme 

MAX ERRORS 10202 #define NIL DEV 9036 #defme NR RS LINES 2695 #defme 

MAX ESC PARMS 13637 #define NIL FILP 20314 #defme NR SCAN CODES 3935 #defme 

MAX FILE POS 2997 #def¡ne NIL HOLE 18821 #defme NR SCSI DRIVE 

2722 #define 

MAX INODE_NR 2996 #defme NIL_INODE 20536 #defme NR_SEGS 2926 #defme 

MAXJNPUT 170 #defme NIL^MESS 3227#defme NR SUBOEVS 10205 #defme 

MAX KB ACK RE1 3028 #defme NIL MPROC 16354#defme NR SUPERS 19508 #defme 

MAX KB BUSY R 13029 #defme NIL MPROC 18628 #defme NR TASKS 2953 #defme 

MAX PAGES 15910 #defme NIL PROC 5169#defme NULL 2921 #defme 
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NU11 1006 #defme 0_RDWR 943 #defme RECOVERYTIME 10207defme 

NU11 607 #defíne 0_TRUNC 934#defme REG BASEO 10122 #defme 

NU11 445 #def¡ne 0_WR0N1Y 942 #defme REG BASEl 10123 #defme 

NU11DEV 3600 #defme PAGE FAU1T VE 5303 #defme REGCOMMAND 10154 #defme 

NU11MAJOR 3596 #defíne PAGEGRANSHI 5315#defme REGCOUNT 10126 #defme 

NWIOGETHOPT1858 #defme PAGE SIZE 15909 #defme REG CT1 10165 #define 

NWIOGETHSTAT1859 #defme PARENB 1149#defme REG_CY1_HI 10129 #defme 

NWIOGIPCONF 1862#defme PARMRK 1134#defme REG_CY1_10 10128 #defme 

NWIOGIPOPT 1864 #defíne PARODD 1150#defme REG DATA 10124 #defme 

NWIOGTCPCONF1871 #defme PARTIA1DATA- 20166 #defme REG ERROR 10145 #defme 

NWIOGTCPOPT 1877 #defíne PARTITIONING 2713#defme REG1DH 10130 #defme 

NWIOGUDPOPT1880 #defíne PARTTAB1EOF 4119#defme REG PRECOMP 10125 #defme 

NWIOIPDROUTE1868 #defme PAR PRINTER 2739 #defme REG SECTOR 10127 #defme 

NWIOIPGROUTE1866 #defíne PATHMAX 172#defme REGSTATUS 10136 #defme 

NWIOIPSROUTE1867 #defme PAUSE 3430 #defme RENAME 3435 #defme 

NWIOSETHOPT 1857 #define PAUSED 16347 #defme REPPROCJSÍR 3667 #defme 

NWIOSIPCONF 1861 #defme PCR 4390#defme REP STATUS 3668 #defme 

NWIOSIPOPT 1863 #define PENDING 5158#defme REOUEST 3651 #defme 

NWIOSTCPCONF1870 #defme PGDN 3825 #defme REVIVE 3455 #defme 

NWIOSTCPOPT 1876 #defme PGUP 3824#defme REVIVING 20032 #defme 

NWIOSUDPOPT 1879 #defíne PID 3688 #defme RIGHT 3823 #defme 

NWIOTCPATTACH1874 #defme PIPE 3439 #defme RMDIR 3437 #defme 

NWIOTCPCONN1872 #define PIPE BUF 173#defme ROBUST 2636#defme 

WIOTCP1ISTEN 1873 #defme PIPE DEV 2689 #defme ROOT DEV 3708 #define 

NWI0TCPSHUTD01875 #defíne PIPE SIZE 19566 #defme ROOT INODE 19559 #defme 

NW_CANCE1 3572 #defme PLUS 3828 #defme RP1 5262 #defme 

NW CIOSE 3568 #defme PORT B 4391 #defme RS232 IRO 4361 #defme 

NW IOCT1 3571 #defme POSITION 3652 #defme RS232_MINOR 11762#defme 

NW OPEN 3567 #defme PR 3690#defme RUNNING 11675#defme 

NW READ 3569 #define PREFETCH 19532 #defme RWX MODES 2987 #defme 

NW WRITE 3570 #defme PRESENT 5277 #defme R ABBS 1470#defme 

N ABS 1497 #defíne PRINTER 3591 #defme R BIT 2988 #defme 

N BSS 1500 #defme PRINTER IRO 4364#defme R KBRANCHE 1478 #defme 

N_C1ASS 1504 #defme PRINTER STACK 5650#defme R_OK 420 #defme 

N COMM 1501 #defme PROC1 3686#defme R PCRBYTE 1472 #defme 

N DATA 1499 #defme PROC2 3687 #defme R PCRIONG 1476#defme 

N SECT 1495 #defme PROC_H 5101 #defme R PCRWORD 1474#defme 

N TEXT 1498 #defme PROC_NR 3649 #defme R RE13BYTE 1477 #defme 

NUNDF 1496 #define PROTECTION_VE5 258#defme RRE11BYTE 1471 #defme 

OFFSET HIGH S 5314#defme PROTO_H 4703 #defme R REllONG 1475 #defme 

OK 225 #defíne PTRACE 3427 #defme R RE1WORD 1473 #defme 

OID MINIX PAR 4124 #defme PTYPX MINOR 11764#defme S 2929 #defme 

ONE SHOT 2018 #defme P FIOPPY 9422 #defme SAPETY BYTES 17693 #defme 

ON1CR 1252 #defíne P PRIMARY 9423 #defme SAFETY C1ICKS 17694 #defme 

ONDEar 1254#defme P_S10T_FREE 5154#defme SAME 25422 #defme 

OPEN 3406 #defíne PSTOP 5160#defme SANOC1DSTOP 782 #defme 

OPEN MAX 167 #defme P_SUB 9424#defme SA_NOClDWAIT 781 #defme 

OPOST 1137 #defíne RAM DEV 3597#defme SA NODEFER 778 #defme 

OPTIONA1IO 3529 #defme RAND MAX 1010#defme SA ONSTACK 776#defme 

OS RE1EASE 2604 #defíne RBT HA1T 437 #defme SA RESETHANO 777 #defme 

OS VERSION 2605 #defme RBT MONITOR 440 #defme SA RESTART 779 #defme 

0VERF10W VECT4338 #defme RBT PANIC 439 #defme SA SIGINFO 780#defme 

OACCMODE 946 #define RBTRE800T 438#defme SCATTEREDIO 3526#defme 

O APPEND 937 #defme RBT RESET 441 #defme SCHAR MAX 113#defme 

OCREAT 931 #defíne READ 3404#defme SCHARMIN 112#defme 

O EXCl 932 #defme READAB1E 5286#defme SCHED RATE 11054#defme 

O NOCTTY 933 #defíne READING 2942 #defme SCIOCCMD 1900#defme 

O NOCTTY 11608 #defme REAL TIME 3609 #defme SCREEN 2706#defme 

O NON BLOCK11609 #defme REBOOT 3465 #defme SCROIL DOWN 13634 #defme 

O NONBLOCK 938#defme RECEIVE 3502#defme SCROLL UP 13633 #defme 

ORDONLY 941 #defme RECEIVING 5157#defme SCSI 3581 #defme 
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SCSI_STACK 5659 #defme SIGNAL 

SCSI_STACK 5663 Wdefine SIGNUM 

SC_ÑORLGLOCAL 2140 «define SIGPENDING 

SC SIGCONTEXT 2149 #defme SIGPIPE737 #define 
SECONDARY IRO 4360 #define SIGPROCMASK 

SECONDS LEFT 3645 #defme SIGOUIT 
SECTOR MASK 9052 ft/define SJGRETURN 
SECTOR SHIFT 9051 #define SIGSEGV735 #define 

SECTOR SIZE 9050 #define SIGSTOP749 #defme 

SEEK CUR 424 #defme SIGSUSPEND 

SF.EK_F.Nn 425 #defme SIGSUSPENDED 

SEEK SET 423 Mefine SIGTERM 

SEGMENT 5280 #defme SIGTRAP 

SEG_NOT_VECTO 5256 #define SIGTSTP 

SENO 3501 #defme SIGTTIN 

SENDING 5156 #define SIGTTOU 

SEPARATE 16349 #define SIGUNUSED 

SERVER_0 4422 #defme SIGUSR1 

SETGID 3441 #defme SIGUSR2 

SETPSW 4309 #define SIG_8LOCK 

SETPSW 4409 #define SIGJ3ATCH 

SETSID 3449 #define SIG CTXT PTR 

SETUID 3424 #define SIG:::DFL 

SET ALAAM 3603 #defme SIG ERR 

SET SYNC_AL 3607 #defme SIG_HOLD 

SET TIME 3605 #define SIGJGN 

SF1 3907 #defme S1GINQU1WE 

SF10 3916 #define SIG MAP 

SF11 3917 #define SIG MSG PTR 

SF12 3918 #defme SIG PENDING 

SF2 3908 #defme SIGPROC 

SF3 3909 #defme SIG SETMASK 

SF4 3910 #define SIG UNBLOCK 

SF5 3911 #define SLASHSCAN 

SF6 3912 #defme BLOCK 

SF7 3913 #defme SMALL STACK 

SF8 3914 #define SMART 

SF9 3915 #/define SPARC 

SHADOWING 2764 #define SOUARE WAVE 

SHADOWING 2774 #defme SRC BUFFER 

SHADOWING 2780 #define SRC PROC NR 

SHADOWING 2791 #define SRC_SPACE 

SHADOW BASE 8814#define SSIZE MAX 

SHADOW MAX 8815#define SS INDLX 

SHADOW O 4426 #defme SS SLLECTOR 

SHIFT 3812 #define ST 

SHRT MAX 119 #define STACK CHANGED1 

SHRT MIN 118 #define STACK FAULT V 

SIGABRT 729 #defme STACK GUARD 

SIGACTION 3459 #defme STACK PTR 

SIGALRM 738 #defme STAT 

SIGBUS 742 #defme STATUS BSY 

SIGCHLD 747 #defme STATUS CRD 

SIGCONT 748 #defme STATUS ORO 

SIGEMT 741 #defme STATUS ERR 

SIGFPE 732 #define STATUS_IDX 

SIGHUP 724 #defme STATUS RDY 

SIGILL 727 #defme STATUSSC 

SIGINT 725 #defme STATUS WF 

SIGIOT 730 #defme STDERR FILENO 

SIGKILL 733 #defme STDIN FILENO 


3443 #defme STDDUTFILENO 432 #defme 

3691 #define STE - 2702 #defme 

3461 #defme STIME 3426#defme 

STOPPED 16351 #defme 

3462 #define STOPPED 11676#define 

726 #defme STREAM MAX 174 Mefine 

3463 #define SUB PER DRIVE 10204 #define 

SUN_4 2619 #defme 

SUN 4 60 2620 #defme 

3460 Merine SUPER BLOCK 19581 #defme 

1632 #define SUPER MAGIC / 9518 Mefine 

739 «define SUPER REY 19519 #define 

728 #define SUPER_SIZE 19565 #defme 

750 #define SUPERJJSER 2916#defme 

751 -define SUPER_V2 19520 #define 

752 #defme SUPER V2_RLV 19521 #defme 

731 #define SUFRA 2714#defme 

734 #define SUSPEND 3530 #defme 

736 #defme SUSPENDED 20030 #define 

785 #defme SU_UID 19527 #defme 

766 #defme SYNC 3433 #defme 

3699 #defme SYN ALRM_5TAC 5640 #defme 

763 Mefine SYNALRMTASK 3587 I/del'ine 

762 #define SYS386_VECTOR 4342 #define 

765 #defme SYSTASK 3615 #define 

764 #define SYSTEMTIME 3681 #define 

788 #define SYS ABORT 3624 #defme 

3697 #define SYS_COPY 3621 #define 

3698 #defme SYS LNDSIG 3635 #define 

5159 #define SYS_EXEC 3622 #define 

3696 #defme SYS„FORK 3619 #define 

787 #define SYS FRESH 3625 #define 

786 #define SYSGBOOT 3627 #define 

13034 #define SYS GETMAP 3636 #define 

3862 #define SYSGETSP 3617 #define 

5637 #define SYS_GID 19529 #defme 

10210 #define SYSJÍILL 3626 #defme 

2756 #define SYS MEM 3629 #defme 

11059 #define SYS NEWMAP 3620 #defme 

3673 #define SYS OLDSIG 3618#defme 

3672 #define SYS SENDSIG 3633 #defme 

3671 #define SYS SIGRETURN 3634#defme 

176 #defme SYS_STACK 5673 #defme 

5212 #defme SYS_TIMES 3623 #define 

5228 #defme SYS TRACE 3630 #define 

2701 #defme SYSJJID 19528 #defme 

7623 #defme SYS UMAP 3628 #defme 

5257 #define SYS_VCOPY 3631 #define 

5151 #defme SYS_VECTOR 4341 #defme 

3689 #define SYS_XIT 3616#defme 

3419 #define S_ABS 1481 #defme 

10137 #define SBSS 1484 #defme 

10142 #define S DATA 1483 #defme 

10141 #define S IFBLK 2328 #defme 

10144 #defme SJFCHR 2330 #defíne 

10143 #defme SJFDIR 2329 #define 

10138 #defme SJFIFO 2331 #defme 

10140 #defme S IFMT 2326#defme 

10139 #defme SIFREG 2327 #defme 

433 #define S IRGRP 2344 #define 

431 #define SJROTH 2349 #defme 
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SIRUSR 2339 #defme 

S IRWXG 2343 #define 

S IRWXO 2348 #defme 

SJRWXU 2338 #defme 

S IS8LK 2357 #defme 

SISCHR 2356 #defme 

S ISDIR 2355 #defme 

SISFIFO 2358 #defme 

S ISGID 2333 #defme 

SISREG 2354 #defme 

S ISUID 2332 #defme 

S ISVTX 2335 #defme 

S IWGRP 2345 tklefine 

S IWOTH 2350 Me/ine 

SJWUSR 2340 «define 

SIXGRP 2346 #defme 

SIXOTH 2351 #defme 

SIXUSR 2341 #defme 

STEXT 1482 #defme 

T 2927 #define 

TA8MASK 11604 #defme 

TA8SIZE 11603 #defme 

TAPE STATO 3663 #defme 

TAPESTATl 3664 #defme 

TASKGATE 5296 #defme 

TASKPRIVILEG5244 #defme 
TASKO 4421 #defme 

TASK REPLY 3456#defme 
TCDRAIN 1841 #defme 

TCFLOW 1842 #define 

TCFLSH 1843 #defme 

TCGETS 1836 #defme 

TCIFLUSH 1208 #defme 

TCIOFF 1215 #defme 

TCIOFLUSH 1210 #defme 

TCION 1216 #defme 

TCOFLUSH 1209 #defme 

TCOOFF 1213 #defme 

TCOON 1214 #defme 

TCSADRAIN 1204#defme 
TCSAFLUSH 1205 #defme 

TCSANOW 1203 #defme 

TCS8RK 1840 #defme 

TCSETS 1837 #defme 

TCSETSF 1839 #defme 

TCSETSW 1838 #defme 

TCTRLDEF 1270#defme 
TDISCARD DEF1289 #defme 
TEOFDEF 1276 #def¡ne 

TEOL DEF 1277 #defme 

TERASEDEF 1278#defme 
TI 5261 #defme 

TIME 3414#defme 

TIMEOUT 10206 #defme 

TIMER0 4392 #defme 

TIMER2 4393 #defme 

TIMERCOUNT11061 #defme 
TIMER FREO 11062 #defme 
TIMERMODE 4394#defme 
TIMES 3440 #defme 

TIMENEVER11687 #defme 
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TINPUTDEF 1271 #defme 

TINTR DEF 1279 #defme 

TIOCGETC 1852 #defme 

TIOCGETP 1850 #defme 

TIOCGPGRP 1846 #defme 

TIOCGWINSZ 1844 #defme 

TIOCSETC 1853 #defme 

TIOCSETP 1851 #defme 

TIOCSFON 1848 #defme 

TIOCSPGRP 1847 #defme 

TIOCSWINSZ 1845 #defme 

TKILLDEF 1280 #defme 

TLNEXTDEF 1288 tklefine 

TLOCAL DEF 1273 «define 

TMINDEF 1281 #define 

TOSTOP 1161 #defme 

TOT STACK SPA 5677 #defme 
TOUTPUT DEF 1272 #defme 

TOUIT DEF 1282 #defme 

TRACE8IT 4408 #defme 

TRACE8IT 4308 #defme 

TRACED 16350 #defme 

TRAP 286 GATE 5298 #defme 

TREPRINT DEF 1287 #defme 

TRUE 2911 #defme 

TR ADDR 15463 #defme 

TRDATA 15464 #defme 

TR-PROCNR 15461 #defme 

TRREOUEST 15462#defme 
TR VLSIZE 15465 #defme 

TSPEEDDEF 1274 #defme 

TSS3SSP0 5964 #defme 

TSS 8USY 5288 #defme 

TSS INDEX 5215 #defme 

TSSSELECTOR 5231 #defme 

TSSTYPE 7710 #defme 

TSTART DEF 1283 #defme 

TSTOPDEF 1284 #defme 

TSUSP DEF 1285 #defme 

TT 2703 #defme 

TTIMEDEF 1286 #defme 

TTY 3517 #defíne 

TTYPX MINOR 11763 #defme 

TTY EXIT 3528 #defme 

TTY FLAGS 3659 #defme 

TTY_IN_8YTES 11602 #defme 

TTYLINE 3656 #defme 

TTYPGRP 3660 #defme 

TTY REOUEST 3657 #defme 

TTY SETPGRP 3527 #defme 

TTY SPEK 3658 #defme 

TTY STACK 5639 #defme 

TYPEH 4501 #defme 

TZNAME MAX 175 #defme 

T EXIT 2216 #defme 

TGETDATA 2210 #defme 

T GETINS 2209 #defme 

TGETUSER 2211 #defme 

T_OK 2208 #defme 

T RESUME 2215 #defme 

T SETDATA 2213 #defme 


T SETINS 2212 #define 

TSETUSER 2214 #defme 

T STEP 2217 #defme 

T STOP 2207 #defme 

UCHAR MAX 114 #defme 

UINT MAX 132 #defme 

UINTMAX 126 #defme 

ULONG_MAX 13 8 #defme 

UMASK 3447 #defme 

UMOUNT 3423 #defme 

UNLINK 3411 #defme 

UNPAUSE 3454 #defme 

UP 3820 i «define 

USER PRIVILEG 5245 «define 

USER O 4423 #defme 

USER TIME 3680 «define 

USHRTMAX 120 #defme 

UTIME 3431 #defme 

VI 19523 #defme 

V1INDIRECTS 19572 #defme 

V1INODES PER 19573 #defme 

V1INODESIZE 19571 #defme 

V1NRDZONES 19501 #defme 

V1NR TZONES 19502 #defme 

V1 _Z0NE_NUM_S 19570 #defme 

V2 19524 #defme 

V2 INDIRECTS 19578 #defme 

V2 INODES PER 19579 #defme 

V2 INODE SIZE 19577 #defme 

V2 NR DZONES 19503 #defme 

V2NRTZONES 19504 #defme 
V 2_Z0NE_NUM_S 19576 #defme 

VDISCARD 1262 #defme 

VECTOR 4370 #defme 

VEOF 1164 #defme 

VEOL 1165 #defme 

VERASE 1166 #defíne 

VIDEO INDEX 5218 #defme 

VIDEO SELECTO 5234 #defme 

VID ORG 13645 #defme 

VINTR 1167 #defme 

VKILL 1168 #defíne 

VLNEXT 1261#defme 

VMIN 1169 #defíne 

VOUIT 1170 #defme 

VREPRINT 1260 #defme 

VSTART 1173 #define 

VSTOP 1174 #defme 

VSUSP 1172 #defíne 

VT100 2710 #defme 

VTIME 1171 #defme 

WAIT 3408 #defme 

WAITING 16345 #defme 

WAITPID 3412 #defme 

WAKEUP 10193 #defme 

WEXITSTATUS 2525 #defme 

WIFEXITED 2524 #defme 

WIFSIGNALED 2527 #defme 

WIFSTOPPED 2528 #defme 

WINCHESTER 3584#defme 

WINCH STACK 5655 #defme 
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WINCH_STACK 5653 #define NO_LIMIT 158#defme _STAT_H 2306 #define 

WINI_0_PARM_V 4374 «define NSIG 722 #defme STOLIB H 1003 #defme 

WINI 1 PARM V 4375 #define PARTITION H 4102 #defme STRING H 605 #defme 

WNOHANG 2521 #defme PC CHOWN RES 469 #defme SYSLIB H 3303 #defme 

WRITE 3405 #defme PC LINK MAX 461 #defme SYSTEM 4205 #define 

WRITEABLE 5287#defme _PC_MAX_CANON 462 #defme SYSTEM 15805 #defme 

WRITE IMMED 20157 #define PCMAXINPUT 463 #defme SYSTEM 19405 #define 

WRITING 2943 #define _PC=NAME_MAX 464#define _SYS KEYMAP 3803 #defme 

WSTOPSIG 2529 #define PC NOTRUNC 467 #defme TABLE 5625 #defme 

WTERMSIG 2526 #define PC PATH MAX 465 #defme TABLE 16504 #defme 

WUNTRACED 2522 #defme PC PIPE BUF 466 #define TABLE 20804 #defme 

W BIT 2989 #define PC_VDISABLE 468 #define TERMIOS H 1103#define 

W OK 419 #defme _POS IX_ARGJMA 142 #defme TIME T 1634#defme 

XLOCK 19536 #defme POSIX CHILD- 143 #defme TYPES H 1607#defme 

XOPEN 19535 #defme POSIX CHOWN- 481 #defme TYPE H 3101 #defme 

XPIPE 19534 #defme POSIX LINK M 144#defme UNISTD H 403 #defme 

XPOPEN 19537 #defme POSIX MAX CA 145 #defme VOID 50 #defme 

XTABS 1253 #defme POSIX_MAXJN 146#defme _VOID 38 #defme 

XT WINI IRO 4362 #defme POSIXNAMCM 147 #defme VOIDSTAR 37 #defme 

X BIT 2990 #defme _POSIX_NGROUP 148#define VOIDSTAR 49 #defme 

X OK 418 #define POSIX NO TRU 480 #defme VOLATILE 52 #defme 

ZMAP 20749 #defme POSIX OPEN M 149 #define VOLATILE 40 #defme 

ZUPER BLOCK 20164 #defme POSIX PATH M 150#defme WAIT H 2516#defme 

_ANSI 24 #define POSIX PIPE B 151 #defme WCHAR T 1023 #defme 

_ANSI 28 #defme POSIX SOURCC 19403 #defme WORD SIZE 2627 #defme 

_ANSI_H 21 #defíne _POSIX_SOURCE 15803 #defme _sighandler- 756#defme 

_AOUT_H 1403 #define POSIX_SOURCE 4203 #define accjime 20601 #define 

RGS 35 #define POSIX SSIZE 154#defme addr 16401 #defme 

ARGS 47 #define POSIX STREAM 152#defme addr 20602 #defme 

BOOT H 3703 #defme POSIX TZNAME 153 #defme adjust 17661 PUBLIC 

CLOCK T 1639 #define POSIX VDISAB 1176#define advance 249855 PUBLIC 

CONFIG H 2601 #define _POSIX VERSID 428 #defme alloc_bit 21926 PUBLIC 

CONST 39 #define PROTOTYPE 34#define al loe inode 21605 PUBLIC 

CONST 51 #defme PROTOTYPE 46#defme alloc mem 18840 PUBLIC 

DIR H 2403 #define PROTOTYPE 20B17 PUBLIC alloc segment 15715 PUBLIC 

ERRNO H 220 #define PTRACE H 2205 #defme alloc zone 21180 PUBLIC 

FCNTL H 910 #define SC ARG_MAX 448 #defme allowed 19120 PUBLIC 

HIGH 2519 #defme _SC_CHILD MAX 449#defme altl 13044 PRIVATE 

101 828 #define _SC_CLK_TCK 451 #defme alt2 13045 PRIVATE 

101 818 #defme SC CLOCKS PE 450#defme ansi colors 13703 PRIVATE 

IOCPARM 1811 #define SC JOB CONTR 454#defme assert 5513#defme 

IOCTL H 183 #define SC NGROUPS M 452 #defme assert 5521 #defme 

IOCTYPE 1813 #defme _SC^OPEN_MAX 453 #defme at_winchester 10294 PUBLIC 

IOC IN 1814 #defme _SC_SAVED_IDS 455 #defme audiojask 5 688 #defme 

IOC INOUT 1816 #defme SC STREAM MA 457 #defme b 20125 EXTERN 

IOC OUT 1815 #defme SC TZNAME MA 4598 #defme b bitmap 20148 #define 

IOC VOID 1812 #defme SC VERSION 456 #defme b data 20142 #defme 

IOR 1829 #define SIGCONTEXT H 2001 #defme b dir 20143 #define 

IOR 1819 #define SIGN 224#defme b_vl_ind 20144 #defme 

IORW 1823 #defme ^SIGN 227#defme b_vl_inO 20146 #defme 

IORW 1831 #define _SIGNAL_H 706#define b^v2Jnd 20145 #defme 

IOW 1830 #define SIGSET T 717#define b_v2_inO 20147 #define 

IOW 1821 #define SIGSET T 1644#defme back over 12607 PRIVATE 

LIMITS H 106 #defme SI ZI . T 41 #defme bad assertion 8935 PUBLIC 

LOW 2518 #define SIZET 53 #defme bad_compare 8947 PUBLIC 

MINIX 4204 #define SIZE^T 1624#defme beep 14300 PRIVATE 

MINIX 15804 #defme _SIZE_T 1018#defme beeping 13671 PRIVATE 

MINIX 19404 #defme SIZLT 610#defme bill_ptr 5191 EXTERN 

MINIX 3103 #defme SIZE T 407 #defme blank color 13664 #define 

MINIX PARTI 4006 #defme SSIZE_T 412#defme boot_paramete 15403 PUBLIC 

NERROR 233 #defme _SSIZE_T 1629#defme boot_paramete 22706 PUBLIC 
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boot_time 

11068 PAIVATE 

cons write 

13729 PAIVATE 

do_lseek 

23367 PUB1IC 

bp_ctlbyte 

9414 Meflne 

control 

1304B PAIVATE 

domem 

15424 PAIVATE 

bp_cYlinders 

9409 Meflne 

conv2 

27522 PUB1IC 

do_mkdir 

23226 PUB1IC 

bp_heads 

9410 Meflne 

conv4 

27536 PUB1TC 

do_mknod 

23205 PUB1IC 

bp_landingzon 9415 Meflne core_sset 

16224 EXTEAN 

dommexit 

16912 PUB1IC 

bp max ecc 

9413 Meflne 

cprocaddr 

5180 Meflne 

do_mount 

25126 PUB1IC 

bpprecomp 

9412 Meflne 

cstart 

6524PUB1IC 

do_newmap 

14921 PAIVATE 

bp_reduced_\ 

vr 9411 Meflne ctty_close 

27151 PUB1IC 

do_nop 

9312 PUB1IC 

bp_sectors 

9416 Meflne 

ctty_open 

27136 PUB1IC 

do_open 

12171 PAIVATE 

buf_count 

27610 PAIVATE 

curcons 

13697 PAIVATE 

do_open 

22951 PUB1IC 

buf_count 

19311 PAIVATE 

current 

5033 EXTEAN 

do_pause 

18115 PUB1IC 

buf hash 

20150 EXTEAN 

data 

16416 Meflne 

do_pipe 

24332 PUB1IC 

bUf_pool 

22679 PAIVATE 

database 

5010 EXTEAN 

do_pty 

11782 Meflne 

bufend 

11694 Meflne 

del_slot 

18926 PAIVATE 

do_rdwt 

9227 PUB1IC 

buffer 

20603 #define 

devio 

27033 PUB1IC 

do_read 

11891 PAIVATE 

buffer 

9135 PAIVATE 

deVioctl 

12763 PAIVATE 

do_read 

23434 PUBLIC 

buflen 

11693 Meflne 

dev_mess 

27025 PAIVATE 

doreboot 

1812B PUB1IC 

bufs_in_use 

20154 EXTEAN 

dev_mess 

25119 PAIVATE 

do_rename 

25563 PUB1IC 

c mode 

20617 Meflne 

dev_mess 

22925 PAIVATE 

do_revive 

26921 PUB1IC 

c ñame 

20618 Meflne 

dev_opcl 

27071 PUB1IC 

dosendsig 

15157 PAIVATE 

call_ctty 

27311 PUB1IC 

dma bytes lef 9025 Meflne 

do set 

26B96 PUB1IC 

call_task 

27245 PUB1IC 

dmap 

20914 PUB1IC 

dosettime 

11230 PAIVATE 

capsoff 

13049 PAIVATE 

do_abort 

15131 PAIVATE 

do_setalarm 

11242 PAIVATE 

capslock 

13046 PAIVATE 

doaccess 

26217 PUB1IC 

dosetsid 

27164 PUB1IC 

cause_alarm 

113IB PAIVATE 

doalarm 

1B056 PUB1IC 

do_setsyn_alr 

11269 PAIVATE 

cauSe_sig 

155B6 PUB1IC 

do_brk 

1762B PUB1IC 

do_sigaction 

17845 PUB1IC 

cdrom_task 

5687 Meflne 

do_cancel 

12220 PAIVATE 

do_sigpending 

17889 PUB1IC 

cfgetispeed 

1236 Meflne 

do_chdir 

25924 PUB1IC 

do_sigprocma 

17898 PUB1IC 

cfgetospeed 

1237 Meflne 

do_chmod 

26124 PUB1IC 

do_sigretum 

15221 PAIVATE 

cfsetispeed 

1238 Meflne 

do_chown 

26163 PUB1IC 

do_sigreturn 

17964 PUB1IC 

cfsetospeed 

1239 Meflne 

do_chroot 

25963 PUB1IC 

do_Sigsuspend 

17949 PUB1IC 

change 

25978 PAIVATE 

do_clocktick 

11140 PRIVATE 

do_stat 

26014 PUB1IC 

check_pending 18330 PAIV ATE 

do_Glose 12198 PRIVATE 

do_stime 

26475 PUB1IC 

check_sig 

18265 PUB1IC 

do_clase 

23286 PUB1IC 

do_sync 

26730 PUB1IC 

child 

20604 Meflne 

do_copy 

15316 PRIVATE 

dotime 

26462 PUB1IC 

cleanup 

17061 PRIVATE 

do_creat 

22937 PUB1IC 

do_times 

15106 PRIVATE 

clear_zone 

24149 PUB1IC 

dodiocntl 

9364 PUBLIC 

dotims 

26492 PUBLIC 

CliCk_tO_hcli 4328 Meflne 

do_dup 

26632 PUBLIC 

do_trace 

15467 PRIVATE 

Click_to_hcli 

4326 Meflne 

do endsig 15294 PRIVATE 

do_trace 

18635 PUB1IC 

click to roun 

2967 Meflne 

do_escape 14045 PRIVATE 

doumap 

15445 PRIVATE 

dock handler 11374PAIVATE 

doexec 

14990 PRIVATE 

do_umask 

26203 PUB1IC 

clock_mess 

27423 PAIVATE 

doexec 

26795 PUBLIC 

do_umount 

25241 PUBLIC 

clock_mess 

26417 PAIVATE 

doexec 

17140 PUBLIC 

do_unlink 

25504 PUB1IC 

clock_mess 

9346 PUBLIC 

do exit 

26825 PUBLIC 

do_unpause 

24560 PUBLIC 

clock_stop 

11489 PUBLIC 

do_fcntl 

26670 PUBLIC 

do utime 

26422 PUBLIC 

Clock_task 

1109B PUBLIC 

dofork 

14877 PRIVATE 

dovcopy 

15364 PRIVATE 

clock_time 

2742B PUBLIC 

dofork 

26757 PUBLIC 

do_vrdwt 

9255 PUBLIC 

comode 

20605 #defme 

do_fork 

16832 PUBLIC 

do_waitpid 

16992 PUBLIC 

code_base 

5009 EXTERN 

do_fstat 

26035 PUBLIC 

do_write 

11964 PRIVATE 

color 

13700 Meflne 

dogboot 

15405 PAIVATE 

do_write 

24025 PUB1IC 

com out 

10771 PRIVATE 

do_get_time 

11219 PRIVATE 

doxit 

15027 PRIVATE 

comsimple 

10843 PRIVATE 

do_getmap 

14957 PAIVATE 

dont_reply 

16208 EXTEAN 

commonopen 22975 PAIV ATE 

do_getset 

18515 PUBLIC 

dont_reply 

19909 EXTERN 

commonsetala 11291 PRIVATE 

do_getsp 

15089 PRIVATE 

dotl 

24719 PUBLIC 

compare 

5522 Meflne 

do_getuptime 

11189 PAIVATE 

dot2 

24720 PUB1IC 

compare 

5515 Meflne 

doioctl 

12012 PAIVATE 

driver_task 

9144 PUB1IC 

con loadfont 14497 PUB1IC 

doioctl 

27184 PUBLIC 

dump_core 

18402 PAIVATE 

cons echo 13794 PRIVATE 

do kill 

15276 PRIVATE 

dup_inode 

21865 PUBLIC 

cons orgQ 14456 PRIVATE 

do_kill 

17983 PUBLIC 

eat_path 

24727 PUBLIC 

cons stop 

14442 PUBLIC 

do_ksig 

17994 PUBLIC 

echo 

12531 PRIVATE 

constable 

13696 PRIVATE 

do_link 

25434 PUB1IC 

eff_grp_id 

20606 #defme 
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eff_user_id 

20607 #defme 

hwint_master 

6143 #defme 

m 

19917 EXTERN 

ega 

5046 EXTERN 

hwint_slave 

6199 #defme 

m 

14812 PRIVATE 

enable_iop 

7988 PUB1IC 

id_byte 

10426 #defme 

mi 

19918 EXTERN 

env_parse 

8865 PUB1IC 

id_longword 

10429 #defme 

mi il 

3149 #defme 

erki 

20606 #defme 

id_word 

10427 #defme 

mi i2 

3150 #defme 

err_code 

19924 EXTERN 

idt 

7756 PRIVATE 

mi i3 

3151 #defme 

err_code 

16218.EXTERN 

in_process 

12367 PUB1IC 

ml_pl 

3152 #defme 

esc 

13047 PRIVATE 

in_transfer 

12303 PRIVATE 

ml_p2 

3153 #defme 

exception 

7512 PU81IC 

inform 

15627 PUBLIC 


3154 #defme 

exec_len 

16403 #define 

init_buffer 

9205 PRIVATE 

m2 il 

3156 #defme 

exec ñame 

16402 #defme 

init_clock 

11474 PRIVATE 

m2_i2 

3157 #defme 

extmemsiz 

5052 EXTERN 

init_codeseg 

7889 PUB1IC 

m2 i3 

3158 #defme 

extpartition 

9593 PRIVATE 

init_dataseg 

7906 PUBLIC 

m2 11 

3159 #defme 

fd 

20609 #defm 

init_params 

10307 PRIVATE 

m2_12 

3160 #defme 

fd2 

20610 #defme 

inode 

20533 EXTERN 

m2_pl 

3161 #defme 

fetch_name 

27447 PUB1IC 

int_gate 

7969 PRIVATE 

m3 cal 

3166 #defme 

file_lock 

20409 EXTERN 

intemipt 

6938 PUB1IC 

m3_il 

3163 #defme 

filp 

20310 EXTERN 

intr init 

7621 PU81IC 

m3_i2 

3164 #defme 

fmd_dev 

27228 PRIVATE 

invalídate 

21280 PUBLIC 

m3_pl 

3165 #defme 

fmd_filp 

22277 PUBLIC 

ioflags 

20611 #defme 

m4 1 

3168 #defme 

fmd_share 

17535 PUBLIC 

irq_table 

5056 EXTERN 

m4 12 

3169 #defme 

fmdpr"c 

18678 PRIVATE 

irq_use 

5057 EXTERN 

m4 13 

3170 #defme 

flush 

27633 PRIVATE 

isconsole 

11767 #defme 

m4 14 

3171 #defme 

flush 

19334 PRIVATE 

isidlehardwar 

5170 #defme 

m4 15 

3172 #defme 

flush 

13951 PRIVATE 

isokprocn 

5171 #defme 

m5_cl 

3174 #defme 

flushall 

21295 PUBLIC 

isoksrc_dest 

5172 #defme 

m5 c2 

3175 #defme 

forbidden 

26242 PUB1IC 

isoksusem 

5113 #defme 

m5_il 

3176 #defme 

forcé timeout 11688 #defme 

isokusem 

5174 #defme 

m5 i2 

3177 #defme 

fp 

19907 EXTERN 

isrxhardware 

5175 #defme 

m5 11 

3178 #defme 

fproc 

20026 EXTERN 

issysentn 

5176 #defme 

m5 12 

3179 #defme 

ífee_bit 

22003 PUB1IC 

istaskp 

5177 #defme 

m5_13 

3180 #defme 

ffee_inode 

21684 PUB1IC 

isuserp 

5178 #define 

m6_fl 

3166 #defme 

freemem 

18879 PUBLIC 

k_atoi 

6594 PRIVATE 

m6_il 

3182 #defme 

free_slots 

18831 PRIVATE 

k_environ 

6516 PRIVATE 

m6_i2 

3183 #defme 

freezone 

21222 PUBLIC 

k_getenv 

6606 PUBLIC 

m6_i3 

3184 #defme 

front 

20152 EXTERN 

k_reenter 

5015 EXTERN 

m6_ll 

3185 #defme 

fs cali 

19920 EXTERN 

k_to_click 

2970 #defme 

mdevice 

9722 PRIVATE 

fsinit 

22625 PRIVATE 

k_to_click 

2972 #defme 

m do open 

9829 PRIVATE 

fuñe 

16404 #defme 

kb ack 

13343 PRIVATE 

mdtab 

9733 PRIVATE 

fimckey 

13405 PRIVATE 

kb_addr 

13041 #defme 

mgeom 

9721 PRIVATE 

ga_program 

14540 PRIVATE 

kb_init 

13359 PU81IC 

m_geometry 

9934 PRIVATE 

gdt 

7755 PUB1IC 

kb_lines 

13067 PRIVATE 

m init 

9649 PRIVATE 

get_block 

21027 PUB1IC 

kb read 

13165 PRIVATE 

m_ioctl 

9874 PRIVATE 

get_boot_pa 

ra 22708 PRIVATE 

kb_wait 

13327 PRIVATE 

m_prepare 

9759 PRIVATE 

get_fd 

22216 PUBLIC 

kbd_hw_int 

13123 PRIVATE 

m_schedule 

9774 PRIVATE 

get_filp 

22263 PU8LIC 

kbd_loadmap 

13392 PUB1IC 

main 

6721 PUBLIC 

get_inode 

21534 PUBLIC 

last dir 

24754 PUBLIC 

main 

16627 PUB1IC 

get_name 

24813 PRIVATE 

ldhjnit 

10133 #defme 

mpin 

22537 PUBLIC 

getpart tabl 9642 PRIVATE 

loadram 

22722 PRIVATE 

make break 

13222 PRIVATE 

get_super 

22047 PUBLIC 

load_seg 

17498 PRIVATE 

mapdmp 

14660 PUB1IC 

get_uptime 

11200 PUBLIC 

load_super 

22832 PRIVATE 

map_key 

13091 PRIVATE 

get_work 

22572 PRIVATE 

lock_mini_sen 

7331 PU8LIC i 

mapkeyO 

13084 #defme 

get_work 

16663 PRIVATE 

lock_op 

22319 PUB1IC 

max_hole 

18985 PU81IC 

group 

20612 #defme 

loCk_pick_pro 

7349 PUBLIC 

maxmajor 

20948 PUB1IC 

grpid 

16405 #defme 

lock_ready 

7361 PUBLIC 

me 

11070 PRIVATE 

handle even 

ts 12256 PUB1IC 

lock_revive 

22463 PUBLIC 

mem 

5024 EXTERN 

hclick_to_phy 4330 #defme 

lock_sched 

7388 PUBLIC 

mem init 

8820 PUBLIC 

held_head 

5013 EXTERN 

lock_unready 

7375 PUBLIC 

mem init 

19005 PUBLIC 

held_tail 

5014 EXTERN 

lost_ticks 

5031 EXTERN 

memtask 

9749 PUB1IC 

hole 

16827 PRIVATE 

lowmemsize 

5053 EXTERN 

merge 

18949 PRIVATE 

hole_head 

16830 PRIVATE 

ls_fd 

20614 #defme 

mess 

24327 PRIVATE 
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millidelay 

11502PUBLIC 

pc_at 

5038 EXTERN 

receive 

3307 #defme 

millielapsed 

11529PUBLIC 

pending_ticks 

11079 PRIVATE 

release 

24490PUBLIC 

milli start 

11516 PUBLIC 

physbtohcli 

4331 #define 

remove_dir 

25777 PRIVATE 

minirec 

7119 PRIVATE 

pick_proc 

7179 PRIVATE 

reply 

22608 PUBLIC 

mini send 

7045 PRIVATE 

pid 

20630 #define 

reply 

16676 PUBLIC 

mkmode 

20615 #defme 

pid 

16407 #defme 

replyjl 

16434 #defme 

mmcall 

16215 (XTERN 

pipe_check 

24385 PUBLIC 

reply_il 

20647 #defme 

mm exit 

16927PUBLIC 

pipe_open 

23176 PRIVATE 

reply_i2 

20648 #defme 

mm in 

16212 EXTERN 

pproc_addr 

5187 EXTERN 

reply_ll 

20646 #defme 

mminit 

16704 PRIVATE 

prev_ptr 

11081 PRIVATE 

replyjl 

16435 #defme 

mm out 

16213 EXTERN 

print_buf 

19312 PRIVATE 

replyjl 

20649 #defme 

mode 

20616 #defme 

print_buf 

27611 PRIVATE 

reply_t2 

20650 #defme 

modemap 

22926 PRIVATE 

printf 

4443 #defme 

reply_t3 

20651 #defme 

mon retum 

5059 EXTERN 

printf 

15913 #define 

reply_t4 

20652 #defme 

mon sp 

5058EXTERN 

printf 

19581 #defme 

reply_t5 

20653 #defme 

mounted 

22067 PUBLIC 

pro 

20631 #define 

reply_type 

16433 #defme 

mp 

16207EXTERN 

proc 

5186EXTERN 

reply_type 

20645 #defme 

mproc 

16341EXTERN 

proc_addr 

5179 #defme 

reprint 

12637PRIVATE 

ñame 

20619 #defme 

procname 

14690 PRIVATE 

request 

16414 #defme 

namel 

20620 #defme 

proc_number 

5181 #defme 

request 

20634 #defme 

namel_length20623 #defme 

proc_ptr 

5018 EXTERN 

res_ptr 

16220 EXTERN 

name2 

20621 #defme 

proc_vir2phys 

5182 #defme 

result2 

16219EXTERN 

name2_length20624 #defme 

processor 

5040EXTERN 

ret mask 

16436 #defme 

name_length 

20622 #defme 

procs_in_use 

16209EXTERN 

revive 

24519PUBLIC 

nametodev 

25299 PRIVATE 

prot_init 

7767 PUBLIC 

reviving 

19912EXTERN 

namelen 

16406 #defme 

protected_mod 

5044 #define 

rm_lru 

21387 PRIVATE 

nbytes 

20625 #defme 

protected_mod 

5042 EXTERN 

rs init 

11778 #defíne 

net_open 

19734 #defme 

psmca 

5039EXTERN 

rw_block 

21243PUBLIC 

new_block 

24190 PUBLIC 

pty_init 

11781 #defme 

rw chunk 

23613PRIVATE 

new icopy 

21821 PRIVATE 

put_block 

21119 PUBLIC 

rw_inode 

21731 PUBLIC 

new mem 

17366 PRIVATE 

put_inode 

21578 PUBLIC 

rw scattered 

21313PUBLIC 

new node 

23111PRIVATE 

put_irq_handl 

7673PUBLIC 

scaO 

2126 #defme 

nextalarm 

11069PRIVATE 

putch_msg 

19313 PRIVATE 

se al 

2127 #defme 

next_pid 

16825PRIVATE 

putch_msg 

27612 PRIVATE 

se a2 

2128 #defme 

nodev 

27337 PUBLIC 

putk 

27619 PUBLIC 

sc_a3 

2129 #defme 

no ñame 

9302 PUBLIC 

putk 

19320PUBLIC 

sc_a4 

2130 #defme 

no_sys 

19161 PUBLIC 

putk 

14408 PUBLIC 

sc_a5 

2131 #defme 

no_sys 

27489 PUBLIC 

rahead 

23805PUBLIC 

sc_bx 

2104 #defme 

nopcleanup 

9338 PUBLIC 

rawecho 

12593 PRIVATE 

se es 

2111 #define 

nopfmish 

9329 PUBLIC 

rd_indir 

23753 PUBLIC 

se ex 

2106 #define 

nr cons 

13695PRIVATE 

rd_only 

20632 #defme 

se di 

2119 #defme 

nr locks 

19911 EXTERN 

rdahed_inode 

19914EXTERN 

se d2 

2120 #defme 

numoff 

13051PRIVATE 

rdahedpos 

19913 EXTERN 

se d3 

2121 #defme 

numap 

15697 PUBLIC 

rdwt_err 

19925EXTERN 

se d4 

2122 #defme 

numlock 13050 PRIVATE 

rdy_head 

5192 EXTERN 

se d5 

2123 #defme 

numpad_map 

13056PRIVATE 

rdy_tail 

5193 EXTERN 

se d6 

2124 #defme 

offset 

20626 #defme 

read_ahead 

23786 PUBLIC 

sc_d7 

2125 #defme 

oldjcopy 21774 PRIVATE 

read_header 

17272 PRIVATE 

sc_di 

2100 #defme 

out_char 1 

3809 PRIVATE 

readmap 

23689 PUBLIC 

se ds 

2099 #defme 

out_process 

12677 PUBLIC 

read_only 

26304PUBLIC 

sc_dx 

2105 #defme 

owner 

20627 #defme 

read_super 

22088PUBLIC 

se es 

2098 #defme 

pdmp 

14613 PUBLIC 

read_write 

23443 PUBLIC 

sc_fp 

2102 #defme 

panic 

6829 PUBLIC 

ready 

7210 PRIVATE 

sc_fp 

2132 #defme 

panic 

19172PUBLIC 

real_grp_id 

20613 #defme 


2096 #defme 

panic 

27500 PUBLIC 

real_user_id 

20633 #define 

se gs 

2095 #defme 

panicking 

27422PRIVATE 

realtime 

11067 PRIVATE 

sc_pc 

2110#defme 

parent 

20628 #defme 

rear 

20153EXTERN 

sc_pc 

2134 #defme 

parse_escape 

13986PRIVATE 

reboot_code 

16429 #defme 

sc_psw 

2112 #define 

partition 

9521 PUBLIC 

rebootcode 

5060 EXTERN 

sc_psw 

2135 #defme 

patch_ptr 

17465PRIVATE 

reboot_flag 

16428 #defme 

sc_retadr 

2108 #defme 

pathname 

20629 #defme 

rebootsize 

16430 #defme 

sc_retreg 

2107 #defme 
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sc_rstreg 

2118 #define 

syn_al_alive 

11075 PRIVATE 

w ñame 

10511 

PRIVATE 

se si 

2101 #defme 

syn_aliTn_task 

11333 PUBLIC 

w_need reset 

10813 

PRIVATE 

sc_sp 

2113 #defíne 

syn_table 

11076 PRIVATE 

w_nextblock 

10241 

PRIVATE 

sc_sp 

2133 #defme 

sys_call 

7008 PUBLIC 

w_opcode 

10242 

PRIVATE 


2114#defme 

sys_task 

14837 PUBLIC 

w_prepare 

10388 

PRIVATE 

sc _ st 

2103 #defme 

t_stack 

5734 PUBLIC 

w reset 

10889 

PRIVATE 

sean keyboard 13432 PRIVA' 

rE taddr 

16415 #defme 

w_sche{!ule 

10567 

PRIVATE 

sched 

7311 PRIVATE 

task 

27026 PRIVATE 

w_specify 

10531 

PRIVATE 

schsdticks 

i 11080 PRIVATE tasktab 

5699 PUBLIC 

w status 

10244 

PRIVATE 

ser init 

14343 PUBLIC 

tell_fs 

19192 PUBLIC 

wtimeout 

10858 

PRIVATE 

ser lines 

13673 #define 

termios_defau 

11803 PRIVATE 

w_tp 

10239 

PRIVATE 

ser size 

13674 #defme 

toggle_scroll 

14429 PUBLIC 

w_waitfor 

10955 

PRIVATE 

ser width 

13672 #defme 

tot mem size 

5025 EXTERN 

waitfor 

10268 

#defme 

scroll screen 13896 PRIVA' 

rE tp 

20637 #defme 

watch_dog 

11072 

PRIVATE 

scsi_task 

5686 #defme 

trúncate 

25717 PUBLIC 

watchdog_proc 

11071 

PRIVATE 

sdesc 

7922 PRIVATE 

tss 

7757 PUBLIC 

whence 

20642 

#defíne 

search_dir: 

24936 PUBLIC 

tty_active 

11774 #defme 

who 

16214 

EXTERN 

seconds 

16408 #defme 

tty_addr 

11757 #defme 

who 

19919 

EXTERN 

seg2phys 

7947 PUBLIC 

tty_devnop 

12992 PUBLIC 

Winchester ta 

10040 

PUBLIC 

selsct_consoll4482 PUBLIC 

tty_icancel 

12891 PRIVATE 

wini 

10230 

PRIVATE 

sand 

3308 #defme 

tty_init 

12905 PRIVATE 

winsize_defau 

11811 

PRIVATE 

ssndrec 

3306 #defme 

tty_open 

27095 PUBLIC 

wipe_inode 

21664 

PUBLIC 

set_6645 14280 PRIVATE 

tty_reply 

12845 PUBLIC 

wr_indir 

24127 

PRIVATE 

set slarm 

18067 PUBLIC 

tty_table 

11670 EXTERN 

wrap 

13668 

PRIVATE 

setleds 

13303 PRIVATE 

tty_task 

11817 PUBLIC 

wreboot 

13450 

PUBLIC 

set vec 

7616 #define 

tty_timelist 

11690 EXTERN 

write_map 

24036 

PRIVATE 

setattr 

12789 PRIVATE 

tty_timeout 

5032 EXTERN 

wtrans 

10237 

PRIVATE 

settimer 

12958 PRIVATE 

tty_wakeup 

12929 PUBLIC 

zeroblock 

24243 

PUBLIC 

shift 

13054 PRIVATE 

umap 

15658 PUBLIC 




sig 

20635 #defme 

umess 

23425 PRIVATE 




sig 

16409 #defme 

unhold 

7400 PUBLIC 




sig_contexl 

: 16424 #defme 

unlink_file 

25818 PRIVATE 




sig_flags 

16423 #defme 

unpause 

18359 PRIVATE 




sig_how 

16422 #define 

unready 

7258 PRIVATE 




sig_msg 

16426 #defme 

update_times 

21704 PUBLIC 




sig_nr 

16417 #defme 

user_path 

19921 EXTERN 




sig_nsa 

16418 #defme 

usizeof 

19515 #defme 




sig_osa 

16419 #defme 

use_id 

16413 #defme 




sig_proc 

18168 PUBLIC 

utime_actime 

20638 #defme 




sig_procs 

5021 EXTERN 

utime_fde 

20640 #defme 




sig_ret 

16420 #defme 

utime_length 

20641 #defme 




sig_set 

16421 #defme 

utime_modtime 

20639 #defme 




sigehar 

12866 PUBLIC 

vga 

5049 EXTERN 




size_ok 

17736 PU8LIC 

vid base 

13670 PRIVATE 




slock 

13052 PRIVATE 

vid_mas k 

13663 PUBLIC 




slock_off 

13053 PRÍVATE 

vid_port 

13667 PRIVATE 




slotl 

20636 #defme 

vid_seg 

13661 PUBLIC 




softscroll 

13669 PRIVATE 

vid_size 

13662 PUBLIC 




sort 

9676 PRIVATE 

vir2phys 

4441 #defíne 




spurious_irq 7657 PRIVATE 

wcommand 

10243 PRIVATE 




stack_byte¡ 

; 16410 #defme 

w count 

10240 PRIVATE 




stack_ptr 

16411 #defme 

w_do_close 

10828 PRIVATE 




stat_inode 

26051 PRIVATE 

w_do_open 

10355 PRIVATE 




status 

16412 #define 

w_drive 

10245 PRIVATE 




stop_beep 

14329 PRIVATE 

w_dtab 

10274 PRIVATE 




stop_proc 

18691 PUBLIC 

w_dv 

10246 PRIVATE 




super_block20745 EXTERN 

w_fmish 

10649 PRIVATE 




super_user 

19908 EXTERN 

w_geometry 

10990 PRIVATE 




susp_count 

19910 EXTERN 

w_handler 

10976 PRIVATE 




suspend 

24463 PUBLIC 

w_identify 

10415 PRIVATE 




switching 

6921 PRIVATE 


10925 PRIVATE 
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